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C3I and Modelling and Simulation (M&S) 
Interoperability 
(RTO-MP-MSG-022) 


Executive Summary 


The NATO Modelling and Simulation Group (NMSG) Conference (MSG-022) “Command, Control, 
Communications and Intelligence (C3) and Modelling & Simulation (M&S) Interoperability” was 
conducted in Antalya, Turkey from 9 to 10 October 2003. All sessions of the Conference were 
unclassified. The Conference audience of 128 persons included experts from NATO countries, Partners- 
for-Peace (PfP), as well as invited nations. Nineteen papers were selected for presentation. In addition, 
two keynote presentations and a capstone paper were given. 


Interoperability of Command, Control, Communications and Intelligence (C31) and Modelling & 
Simulation (M&S) systems is a necessary requirement for effective and efficient support of future military 
operations, including; procurement, acquisition, test and evaluation, training, and application of necessary 
functionality within the ongoing operation. In order to be able to support this task, a close understanding 
and knowledge of the software architecture, the communications protocols, possible interfaces, data and 
object models, and the management procedures used on the C3I and M&S side is mandatory. 


The majority of the actual solutions are interface driven to link stove-piped developed legacy systems. 
The use of common reference models facilitating the necessary data alignment and information exchange 
is a first step to broader and reusable solutions. Newer systems with configurable interfaces making use of 
these technical potentials are pointing to the next set of solutions. 


Although the number of engineering solutions linking C3I and M&S systems is relatively high, the 
amount of “documented lesson learned” is relatively small. Most solutions are ad-hoc, not following a 
common or general scheme. In order to establish a standard way — which increases reusability and 
collaboration and reduces costs and risks of affected projects and programmes — this has to change. 
Documentation of applied methods and procedures must be captured and evaluated. 


Technical Reference Models (TRM), such as the one developed by the Simulation Interoperability 
Standards Organization (SISO), are applicable to NATO standards and will facilitate the perception of 
common migration paths and reusability of legacy components in future systems. National solutions can 
be mapped to these TRMs to facilitate joint and combined C3] system and federation planning. 


The Command and Control Information Exchange Data Model (C2TEDM), which is the NATO Standard 
Allied Data Publication No. 32 (ADatP-32) and the Data Model of Choice for the Multinational 
Interoperability Programme (MIP) connecting NATO’s Command and Control systems and the basis for 
various national C3I systems, is successfully used for data alignment in various national projects. 
C2IEDM was not only applied to C3I systems, but also to M&S data alignment. As the NATO Data 
Administration Group (NDAG) is already using the C2IEDM for data management for C3I systems, the 
extension to M&S systems is perceived as a valuable option. 


Future interoperability standards will depend much more on commercial solutions than it has been the case 


in the past. New standards as the next generation of the Unified Modelling Language version 2.0 (UML 
2.0), the Extensible Mark-up Language (XML), web services, and the Model Driven Architecture (MDA) 
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are applicable to C3I systems as well as to M&S systems. They support actual developments to make use 
of internet technologies — which are in particular observable in the United States where the definition of 
development of the Global Information Grid (GIG) was recently initiated. 


Finally, a closer relationship between the NATO M&S Group and the Simulation Interoperability 
Standards Organization (SISO), in particular the observation, and where appropriate, active participation 
in study groups and product development groups, is likely to support the process of gaining C3I and M&S 
interoperability effectively. A formal liaison — based upon the initial informal relationship established by 
Dr. Jean-Louis Igarza, first chief scientist of the NMSG — will ensure that the NMSG is aware of the latest 
developments of the simulation standardisation world and can influence the new standards by bringing in 
the NMSG requirements as early as possible, 1.6., before the standards are established. A closer 
relationship with EUCLID projects also may be valuable. 


In summary, the conference was very successful. State of the art solutions as well as ideas and 
requirements for necessary future research and development were presented and the views of the armed 
forces, industry, government, and academia were discussed. The papers presented during the conference 
provided a good overview of what has been done in NATO and NATO/PfP nations, what is the state of the 
art, and the next steps. 
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Interopérabilité entre le (91 et la modélisation et 
la simulation (M&S) 
(RTO-MP-MSG-022) 


Synthese 


Une conférence sur « L'interopérabilité du C3I et de la modélisation » a été organisée par le Groupe 
OTAN sur la modeélisation et la simulation (NMSG), a Antalya, en Turquie, les 9 et 10 octobre 2003. 
Toutes les sessions de la conférence étaient non classifiées. L’assistance, au nombre de 128 personnes, 
comprenait des spécialistes des pays membres de l|’OTAN, des pays du PfP, ainsi que des pays invités. 
Dix-neuf communications ont fait l’objet d’une sélection. En outre, deux discours d’ouverture et une 
allocation de cléture ont été prononcés. 


L’interopérabilité entre les systémes de commandement, contrdéle, communications et renseignement (C3]) 
et les systémes de modeélisation et de simulation (M&S) est une condition indispensable au soutien réel et 
efficace des futures opérations militaires, ἃ savoir : approvisionnement, acquisition, essais et évaluation, 
entrainement et mise en ceuvre des fonctions nécessaires dans le cadre des opérations en cours. Le soutien 
de l’interopérabilité passe par une bonne compréhension et une connaissance approfondie des 
architectures logicielles, des protocoles de communication, des interfaces possibles, des modéles de 
données et d’ objets, ainsi que des procédures de gestion utilisées pour le (31 et la M&S. 


La majorité des solutions actuellement proposées font appel a des interfaces pour établir des liens entre 
systémes classiques distincts. Dans un premier temps, la mise en ceuvre de modeéles de référence 
commune, facilitant l’échange et l’alignement des données nécessaires ouvrirait la voie a des solutions 
réutilisables plus générales. Des systémes plus récents, dotés d’interfaces configurables qui exploitent ces 
possibilités techniques, laissent prévoir de nouvelles solutions. 


Malgre l'abondance relative de solutions techniques s'appliquant au (31 et ἃ la M&S, relativement peu de 
documents existent sur "les enseignements tirés" de cette expérience. La plupart des solutions sont du 
type ad hoc, et ne suivent pas un schéma commun ou général. Cette situation doit changer en faveur 
d’une approche standard — qui donnerait plus de possibilités de réutilisation et de coopération et 
permettrait de réduire les coiits et les risques pour les projets et les programmes affectés. II faudra saisir 
et évaluer les méthodes et procédures a appliquer. 


Des modéles de référence techniques (TRM), comme celui développé par |’Organisation de normalisation 
de l’interopérabilité en matiére de simulation (SISO), sont applicables aux normes de ὍΤΑΝ et 
faciliteront la perception de chemins de migration communs, ainsi que la réutilisation d’éléments 
classiques dans les systémes futurs. Des solutions nationales peuvent étre établies en fonction de ces 
TRM afin de faciliter la conception de fédérations et de systémes C3] interarmées et multinationaux. 


Le modéle d’échange d'informations de commandement et contréle (C2IEDM), matérialisé par la 
publication normalisée ADatP-32 de l’OTAN, qui est le modéle de données de choix du Programme 
d’interopérabilité multinationale (MIP) reliant les systemes de commandement et contréle de l'OTAN, 
ainsi que la base de différents systemes C3] nationaux, a été mis en ceuvre avec succés pour l'alignement 
des données dans le cadre de plusieurs projets nationaux. Le C2TIEDM n’a pas été appliqué uniquement a 
des systemes (31, mais aussi a l’alignement de données M&S. Etant donné que le Groupe pour 
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V’administration des données de l’OTAN (NDAG) utilise déja le C2IEDM pour la gestion de données de 
systémes C3], son extension aux systemes M&S est persue comme une option intéressante. 


A Vlavenir, les normes d’interopérabilité dépendront beaucoup plus de solutions commerciales que par le 
passé. Les nouvelles normes, telles que la prochaine génération du Langage de modélisation unifié 
Version 2.0 (UML 2.0), le Langage de balisage extensible (XML), les services du Web, et les 
Architectures guidées par modéle (MDA), sont applicables aux systémes C3] ainsi qu'aux systémes M&S. 
Ils supportent les développements actuels destinés ἃ exploiter les technologies de |’Internet — qui sont 
surtout disponibles aux Etats-Unis, οὐ le développement du Réseau global de l'information (GIG) a 
récemment été lancé. 


La création de liens plus étroits entre le groupe M&S de lOTAN et I'Organisation de normalisation de 
l'interopérabilité en matiére de simulation (SISO), et en particulier l’observation, ainsi que, le cas échéant, 
la participation active a des groupes d’étude et des groupes de développement de produits, permettrait de 
faire avancer l'interopérabilité efficace entre le C3I et la M&S. Une liaison officielle — basée sur les 
relations officieuses établies par le Dr. Jean-Louis Igarza, le principal expert scientifique auprés du NUSG 
— permettra au NMSG d’étre informé des derniers développements dans le domaine de la normalisation de 
la simulation. Le groupe pourra ainsi faire valoir ses souhaits en matiére de normalisation avant 
l’établissement des normes. II serait sans doute intéressant aussi d’établir des liens avec des projets 
EUCLID. 


Pour résumer, la conférence a été trés réussie. Des solutions faisant appel a des techniques de pointe ont 
été présentées, ainsi que des propositions et des besoins en matiére de projets de recherche futurs. Les 
points de vue des militaires, des industriels, des représentants des gouvernements et des universitaires ont 
été débattus. Les communications présentées lors de la conférence ont fourni un bon aperc¢u des travaux 
réalisés dans les pays de l’OTAN, ainsi que dans les pays du PPP, de |’état actuel des connaissances et des 
initiatives qui restent a prendre. 
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Technical Evaluation Report 
MSG-022/SY-003 Conference on 
C3I and M&S Interoperability 


Prepared by Dr. Andreas Tolk 
Virginia Modeling Analysis & Simulation Center (VMASC) 
Old Dominion University, Norfolk, Virginia 23529, United States 


atolk@odu.edu 


OVERVIEW 


The NATO Modelling and Simulation Group (NMSG) Conference (MSG-022) “Command, Control, 
Communications and Intelligence (C3) and Modelling & Simulation (M&S) Interoperability” was 
conducted in Antalya, Turkey from 9 to 10 October 2003. Αἰ sessions of the Conference were 
unclassified. The Conference audience of 128 persons included experts from NATO countries, Partners- 
for-Peace (PfP) nations, as well as invited nations. 


Out of the 30 submitted abstracts, 19 Papers were selected for presentation. In addition, two keynote 
presentations and a capstone paper were given. This technical evaluation report summarizes the core 
ideas and results presented in this wide variety of valuable contributions from NATO countries, PfP 
nations, and invited nations. In addition, for each category, the report provides an overview of the 
discussions conducted during the conference following each presentation. 


INTRODUCTION 


The importance of Modelling and Simulation (M&S) is now largely recognised within NATO. Among 
various military applications of M&S within the Alliance, Operational Support and Training are identified 
as high priority areas. In parallel NATO has developed an important activity in the Command, Control, 
Communication and Intelligence (C31) Systems as the backbone support of military activities. 


Whilst C3I and M&S domains have many technical similarities, they have developed along separate tracks 
in the Alliance, as in many nations, sometimes differing by their purposes and priorities. As an example, 
different standards have been developed in parallel and are not largely understood and shared in both 
communities. The NATO Modelling and Simulation Master Plan — the capstone document for M&S 
systems — does not mention the NATO C3 Technical Architecture — the capstone document for C31 
systems — and vice versa. For the efficient support of planning, training, and executing of operations, as 
well as NATO procurement and doctrine development, this gap should be closed. Consequently, the main 
objective of this conference was to contribute to a better understanding of and an improvement in 
interoperability between C3I and M&S systems as a first step towards a common information technology 
(IT) infrastructure supporting M&S as well as C3I systems, thus, overcoming the shortfalls of interface 
driven solutions. Following topics were given as a guideline for the authors: 


e Lessons learned from past experience in linking C3] and M&S, 
e Current Joint use of C3I and M&S in Computer Assisted Exercises (CAX), 


Technical Evaluation Report on the papers presented at the MSG-022/SY-003 Conference on 
“C31 and M&S Interoperability”, held in Antalya, Turkey, 9-10 October 2003, and published in RTO-MP-MSG-022. 
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e Interoperability and data standards, 
e Future projects. 


In addition, the conference addressed the themes of research, development and cost-effective co-operative 
application of C3I and M&S systems. Furthermore, the Data Consistency and Translation between (31 
and Simulations was perceived to be a first valuable step into this direction. 


That these topics are generally of great interest can already be derived from the number of abstracts 
submitted following the call for papers. Twice the number of possible presentations was evaluated, and 
unfortunately not every valuable abstract could be accepted. The resulting paper selection consequently 
represents the leading edge of research, development, and application of methods, procedures and IT 
solutions supporting C3I and M&S Interoperability within NATO and PfP nations. 


The Keynote speakers supported this perspective: 


e Brigadier General B. Pekar, Turkish General Staff, stressed the necessity of appropriate training 
for efficient operational availability. Modelling and Simulation is the most economic and 
appropriate support to fulfil this requirement. The integration of Command and Control systems 
to enable “Train as they fight” is a cornerstone of realistic training. A tight relation between 
armed forces, industry and academia is necessary to support these efforts. The NATO fellowship 
programme, and in particular the Turkish Canadian cooperation in the C3I and M&S 
Interoperability domain, was stressed as another important factor by General Pekar. 


e Dr. F. A. Yarman, General Manager of Havelsan, showed the potentials of the Turkish M&S 
market from the local defence industry to highlight the economic importance of the issue dealt 
with in this conference. He used the simulation based acquisition idea to show the benefits of 
using M&S stressing the importance of the scientific process of sound modelling. Synthetic 
environments, physical modelling, computer generated forces, and scenario generations, and after 
action review and replay were presented as the core domains of necessary military M&S efforts. 
C31 must be an integrated part of the resulting architecture. Furthermore, Dr. Yarman stressed the 
necessity of standards for effective reusability and collaboration and gave examples for migration 
procedures. 


All presentations given during this conference perceived the role of M&S in Training and Education to be 
established, in particular the use of M&S for CAX. CDRE Jon Welch, NATO Allied Command 
Transformation (ACT), Norfolk, Virginia, U.S.A., presented the important new role of M&S in 
transformation in his capstone speech. NATO is transforming to fulfil its new mission. To steer the 
process and align sub-processes, the ACT is being established. Within the ACT, in particular Joint 
Education & Training and Joint Concept Experimentation will need M&S support and has (31 and M&S 
interoperability as a necessary requirement to fulfil the new tasks effectively and efficiently and to 
establish the envisioned NATO Transformation Process. In summary, M&S will play a pivotal role in 
transformation. 


Within the following sections, the core ideas and discussion results are grouped by the topics given in the 
authors’ guideline. When writing this technical evaluation report it was not intended to recite paper 
abstracts or give pure summaries, but to show the general developments and common ideas allowing the 
analyses of trends within NATO/PfP nations and other invited nations. Therefore, only the contributions 
to this objective are addressed in this report. As previously mentioned, all the papers are very valuable 
and it is highly recommended to read and analyse all underlying trends and references, in particular when 
dealing with special issues. The papers will be referenced using the numbers assigned in the official 
programme, such as [P-01] to reference to the paper “Overview of Recent Findings of the Study Groups of 
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the Simulation Interoperability Workshop dealing with C3I and M&S Interoperability”. 


LESSONS LEARNED FROM PAST EXPERIENCES IN LINKING C3I AND M&S 


The domain of linking C3I and M&S systems is recognized more and more as an engineering task in the 
NATO nations — and in non-NATO nations as well — and therefore lessons learned are now being 
generated. Examples of such lessons learned are summarized in [P-01] and [P-02]. However, a standard 
way to link C3I and M&S is not yet established. The SISO Technical Reference Model for C4ISR and 
Simulation System Interoperability presented in [P-01, P-18] is a first promising step, but actually most 
link solutions are “one of a kind” and in general not easily reusable. 


Another often observed shortcoming is documented in [P-02], and the discussion showed the validity of 
these perceptions as well: In general, prototype developers are neither HLA nor C3] experts, which results 
in proprietary solutions. The use of standards is seldom the case with prototype developments, and 
unfortunately, many M&S systems in operational use are still on the prototypical implementation level. 
Standardization is often seen as something that can be dealt with later in the project, i.e., after the proof of 
feasibility. This procedure generally makes standardisation unnecessarily costly, as re-implementations 
and updates are more expensive than using the standard from the beginning of the project. In particular 
recommended or mandated standards, such as given in the NATO C3 Technical Architecture and the 
NATO M&S Master Plan, should already be used in the initialisation phase. The increasing use of 
testbeds with necessary integration capabilities may help to overcome this shortcoming. 


However, it would be naive to assume that coupling of (31 and M&S systems would be a pure 
engineering problem. Even if we could solve the linkage without additional challenges, the resulting 
solutions are not necessarily sufficient. This was pointed out in [P-09]. Actually, many M&S challenges 
have to be solved, such as multi-resolution challenges. The discussion showed furthermore, that 
increasingly multilevel-security challenges have to be solved as well. 


For coping effectively and efficiently with C3I and M&S interoperability issues, deep knowledge of IT 
architectures, data and object models, and applied management procedures of both communities is 
mandatory. A good overview of most relevant NATO C3 interoperability standards and the applicability 
of respective reference models are given in [P-18]. The standards referred to in this paper are a minimal 
set of necessary knowledge of M&S experts responsible for NATO C3I and M&S interoperability. 


CURRENT JOINT USE OF C3I AND M&S IN CAX 


The M&S application domain of training and education, in particular Computer Assisted Exercises 
(CAX), is likely to be the most visible mature application for NATO. Keynotes and presentations 
supported this view. 


In [P-02] the NATO CAX “Cannon Cloud 2002” was evaluated to illustrate the use of C3I and M&S 
within NATO for training and education. Cannon Cloud 2002 successfully demonstrated the utility of 
integrating entity-level simulations into an operational level CAX using distributed techniques. [P-02] 
used Cannon Cloud 2002 as a case study highlighting the main domains of C3I and M&S interoperability, 
which includes typical simulation-to-simulation challenges, such as aggregation and other multiple 
resolution issues. The similar national use of (31 and M&S supporting CAX was the topic of various 
papers, including [P-05, P-06, P-09]. 


NATO politics require that NATO partners and allies participate in common exercises. Logically, new 


NATO partners and PfP nations use CAX to gain experience in the application of NATO doctrine and 
procedures. [P-06] shows how this has been done in Slovakia in an exemplifying way. These new CAX 
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systems and federations are normally planned with the purpose of distributed use and integration with 
other NATO/PfP national centres. 


The gateway solution connection between C3I and M&S applications prototypically implemented for the 
Royal Army of the Netherlands as presented in [P-09] can be seen as a state of the art implementation of 
C3I and M&S interoperability. Although common infrastructures are envisioned for future applications, 
interfaces like this are likely to be the rule for the mid term future. Similar approaches can be found in 
various national examples (see, e.g. [P-01]). 


It should be pointed out, that some papers, e.g. [P-05, P-09, P-11], are dealing with the potential and 
ongoing research to use M&S within C3I systems to support the operational decision making process by 
applying M&S in the harmonized suite of decision support systems. Although the technical challenge to 
couple C3I and M&S is at least comparable to CAX, the requirements to be fulfilled by the M&S systems 
to support real operations are higher than for the application within training and education. Credibility of 
the M&S application and the necessary Verification and Validation was mentioned in the discussions. 


INTEROPERABILITY AND DATA STANDARDS 


In the discussions following various presentations on interoperability and data standards it was pointed out 
— in particular from the academia present at the conference — that data exchange is necessary for C3I and 
M&S interoperability, but not sufficient. While actual standards and solutions are targeting the 
implementation level, meaningful interoperability can only be reached on the modelling level. Actually, 
the modelling level is aligned by additional procedures to follow when setting up federations (as 
documented in the Federation Development and Execution Process). The results of the Simulation 
Interoperability Standards Organization (SISO; see http://www.sisostds.org) Study Groups are supporting 
this perception [P-01]. New standards will take this into account, such as the Model Driven Architecture 
(MDA) approach of the Object Management Group (OMG; see http://www.omg.org/mda). In the section 
on Future Projects, some additional information concerning the applicability of these new standards for 
NATO M&s, C3I, and C3] and M&S interoperability will be given. 


The use of a common source to initialise (31 and M&S systems is one of the most obvious uses of 
common data standards. The second immediately obvious use is the sharing of information by using 
standardized shared data elements. Both ideas were part of the presentation of the French project 
ESTHER [P-05]. For the initialisation, XML documents are created from the ESTHER data source. All 
participating systems and components are able to map the XML tagged information to their own 
presentation. The NATO Reference Database presented as part of [P-02] is also pointing into this 
direction. The same approach is furthermore used for the German Integrated Army Modelling and 
Simulation Data Network [P-08]. It is of special interest that the NATO Command and Control 
Information Exchange Data Model (C2TIEDM, NATO Standard ADatP-32) was enhanced and extended 
for this purpose following the C2IEDM extension rules. Generally, data interoperability is seen as a 
necessary precondition for C3I and M&S interoperability, and using an established C31 originated data 
model as the generic hub will support the vision of C3I and M&S interoperability more efficiently than it 
would be the case using a proprietary or newly developed data model. 


The Extensible Mark-up Language (XML) is used in various applications with great success, examples 
given during this conference can be found in [P-05, P-08, P-11]. However, the use of XML doesn’t 
ensure interoperability per se, but that management of the tags used for the exchange of information is 
mandatory. The actual namespace management of the C3I community therefore must be reflected, or — 
where possible — used for XML based data information share. Potential future mark-up languages, such as 
the recently introduced Simulation Reference Mark-up Language (SRML; see www.w3.org/TR/SRML/), 
will support interoperability. However, without being accompanied by aligned management processes, 
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meaningful interoperability cannot be reached. 


HLA is not the only method of choice to reach interoperability between C3I and M&S. The use of open 
and commercially supported interoperability enablers was presented in various papers. In particular, the 
use of Internet technologies [P-10], Extensible Mark-up Language (XML) [P-12], Unified Modelling 
Language (UML) [P-14] and the Common Object Request Broker Architecture (CORBA) [P-13] should 
be mentioned. The Model Driven Architecture (MDA) of the Object Management Group (OMG) is 
supporting all these solutions and seems to have the potential to become the overarching coordinating 
approach. These approaches are not mutual exclusive but complementary with huge overlaps. A common 
overarching principle, such as the MDA, enables the community furthermore to generalize enhancements 
and extension, such as that recommended for UML in [P-14]: contrarily to having this valuable work 
available only in UML, the approach to align the various techniques using the MDA allows the reflection 
of the results in neighboured methods as well. As MDA is applied in C3I development, there seems to be 
a good applicability of the MDA to C3I and M&S interoperability issues. Furthermore, the migration to 
web enabled solutions is supported by the MDA, so that new developments in the C3I community, in 
particular the Global Information Grid (GIG, see U.S. DoD Directive 8100.1), can be coped with. 


Modelling issues dealt with in this conference will support the identification of necessary levels of 
interoperability as well as critical connections between C3I and M&S. In the mid term future, approaches 
such as presented in [P-15, P-16] will enable the evaluation of C3I architectures as well as (31 and M&S 
architecture before these are established and will support the definition of necessary information exchange 
requirements as well as process harmonization requirements. In the long term, better and even automatic 
support may become an option if software agents can make use of these architecture models effectively 
and efficiently. To this end, however, meta-data of the models of the C3I and M&S architecture are 
needed describing the reliability of the data, constraints and assumptions of the model, pedigree of data 
and models, and the other meta-data as exemplarily specified in the NATO Code of Best Practise for 
Command and Control Assessment (see http://www.dodccrp.org/nato_supp/nato.htm). Examples helping 
to answer the question why such data and meta-data are so important are given in [P-17] dealing with 
essential precondition for coupling model based information systems. Furthermore, the paper shows that 
interoperability of models is often a matter of the alignment of the conceptual models, not the 
implementation level. The fact that two models can be linked to exchange “bits and bytes” doesn’t imply 
that the resulting federation operationally makes sense. For meaningful interoperability, the conceptual 
models must be mapped to each other as well. The domain of “composability” dealt with under the 
umbrella of SISO and DMSO also contributed to the discussion. Meaningful interoperability on the 
implementation level requires composable models on the conceptual level. 


FUTURE PROJECTS 


The use of new standards and their applicability to NATO/PfP M&S, (931, and C3I and M&S 
interoperability was the topic of various discussions. Explicitly mentioned were the Model Driven 
Architecture (MDA) developed by the Object Management Group, Web Services, and the Extensible 
M&S Framework (XMSF). As previously mentioned, the actual M&S standards Distributed Interactive 
Simulation (DIS) and High Level Architecture (HLA) are targeting the implementation level while 
meaningful interoperability requires alignment on the conceptual level. The various levels of system 
interoperability are defined in [P-08] and the definition is supported by ongoing work within academia and 
industry. A common ontology is the objective of various projects initiated by several nations; examples 
are given in [P-01, P-05, P-08, P-09]. Data Repositories and M&S Repositories, as mentioned in [P-02, P- 
12, P-19], are a step into the right direction, but to establish an aligned approach; the establishment of a 
coordination organization is necessary. To reach this goal, [P-09] recommends the development of a 
“Master Plan” to align the software architectures and the data/object models supporting NATO (31 and 
M&S interoperability. The analyses of national contributions and conducting additional feasibility studies 
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under aegis of the NMSG are valid options for future projects. 


Additionally to this technical research and development, action on the bureaucratic side is also needed, 
e.g., capability packages and requirement analysis for actual C3I solutions and possibly future STANAG 
development must be addressed concerning C3I and M&S interoperability. Examples how this is done in 
the domain of Tactical Missile Defence are given in [P-02]. In particular the Missile Defence Testbed 
Vision is a valuable example of common requirement derivation and analyses. An example of how this 
was done for STANAG development for low-level tactical data exchange is given in [P-12]. This paper 
also comprises a list of challenges to achieving low level tactical data exchange, which can easily be 
generalized for C3Il and M&S interoperability. Additionally, recommendations for other actions 
concerning the alignment of NC3TA and M&S activities and the use of the SISO C4ISR/Sim Technical 
Reference Model within the NATO standard are given in [P-18]. 


One key enabler of new infrastructures is the existence of migration concepts for legacy solutions. The 
ESTHER project of the French Armed Forces [P-05] shows one possible way to integrate Live, Virtual, 
and Constructive (31 and M&S systems using common standards for new component development as 
well as wrapping and interfacing legacy systems. Although the discussions showed that there are 
alternatives, the example given in this paper is state of the art and can serve as a general example. 


Although not directly connected to the challenge of C3I and M&S interoperability, the Training and 
Education Enhancement Programme (TEEP) [P-03] will influence the future development. TEEP 
comprises — among other valuable issues — interoperability challenges to support primarily Partnership- 
for-Peace (PfP) efforts. Objective is the establishment of a multinational learning environment in support 
of interoperability between allies and partners, including various CAX, and integrating Advanced 
Distributed Learning (ADL) and Simulation. In support of this, SACLANT/ACT has been established as 
the single focus to organize and coordinate NATO/PfP efforts and harmonise it with national efforts. In 
which way this will influence future developments is open, but without doubt the alignment of necessary 
participating standards — such as the High Level Architecture (HLA), the Synthetic Environment Data 
Representation and Interchange Specification (SEDRIS), and the Shareable Content Object Reference 
Model (SCORM) — will be a main issue. 


The use of the Internet for future Advanced Distributed Simulation Systems solutions was the core idea 
presented in [P-10], focussing on Peer-to-Peer (P2P) applications. The NetSim project of the Swedish 
Defence Research Agency is analysing the usability of HLA standards in this new environment. In the 
United States, the Extensible M&S Framework (XMSF, see http://www.movesinstitute.org/xmsf) group is 
doing related similar research. Leading experts see “M&S as the next killer application on the Web” (as 
stated by Dr. Anita Jones on 6. September 2002 during the XMSF Symposium at George Mason 
University, Fairfax, Virginia, U.S.A.). Future projects are likely to make use of these technologies. This 
vision is supported by the ideas comprised in [P-19], presenting an overview of the European Co- 
Operation for the Long-term in Defence (EUCLID) RTP 11.13. The products and results are published on 
http://www.euclid1113.com. An analysis of the usability of their results in the domain of NATO C3] and 
M&S interoperability may be valuable. As EUCLID RTP 11.13 is tightly related to web based 
distribution of M&S application based on the concepts of the High Level Architecture (but not necessarily 
limited to its implementation), this should be technically feasible with minimal effort; however, the 
contractual issue may become an obstacle. 


SUMMARY AND RECOMMENDATIONS 


Interoperability of C3I and M&S systems is a necessary requirement for effective and efficient support of 
future military operations, including procurement, acquisition, test and evaluation, training, and 
application of necessary functionality within the ongoing operation. In order to be able to support this 
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task, a close understanding and knowledge of the software architecture, the communications protocols, 
possible interfaces, data and object models, and the management procedures used on the C3I and M&S 
side is mandatory. 


The majority of the actual solutions are interface driven to link stove-piped developed legacy systems. 
The use of common reference models facilitating the necessary data alignment and information exchange 
is a first step to broader and reusable solutions. Newer systems with configurable interfaces making use 
of these technical potentials are pointing to the next set of solutions. 


Although the number of engineering solutions of linking C3I and M&S systems is relatively high, the 
amount of “documented lesson learned” is relatively small. Most solutions are ad-hoc solutions, not 
following a common or general scheme. In order to establish a standard way — which increases reusability 
and collaboration and reduces costs and risks of affected projects and programmes — this has to change. 
Documentation of applied methods and procedures must be captured and evaluated. 


Technical Reference Models (TRM), such as the one developed by the Simulation Interoperability 
Standards Organization (SISO), are applicable to NATO standards and will facilitate the perception of 
common migration paths and reusability of legacy components in future systems. National solutions can 
be mapped to these TRMs to facilitate joint and combined C3] system and federation planning. 


The Command and Control Information Exchange Data Model (C2IEDM), which is the NATO Standard 
Allied Data Publication No. 32 (ADatP-32) and the data model of choice for the Multinational 
Interoperability Programme (MIP) connecting NATO’s Command and Control systems and the basis for 
various national C3I systems, is successfully used for data alignment in various national projects [P-08]. 
C2IEDM was not only applied to C3I systems, but also to M&S data alignment. As the NATO Data 
Administration Group (NDAG) is already using the C2IEDM for data management for C3I systems, the 
extension to M&S systems is perceived as a valuable option. 


Future interoperability standards will depend much more on commercial solutions than it has been the 
case in the past. New standards as the next generation of the Unified Modelling Language version 2.0 
(UML 2.0), the Extensible Mark-up Language (XML), web services, and the Model Driven Architecture 
(MDA) are applicable to C3I systems as well as to M&S systems. They support actual developments to 
make use of Internet technologies — which are in particular observable in the United States where the 
definition of development of the Global Information Grid (GIG) was recently initiated. 


Finally, a closer relationship between the NATO M&S Group and the Simulation Interoperability 
Standards Organization (SISO), in particular the observation, and where appropriate, active participation 
in Study Groups and Product Development Groups, is likely to support the process of gaining C3I and 
M&S interoperability effectively. A formal liaison — based upon the initial informal relationship 
established by Dr. Jean-Louis Igarza, first Chief Scientist of the NMSG — will ensure that the NMSG is 
aware of the latest developments of the simulation standardisation world and can influence the new 
standards by bringing in the NMSG requirements as early as possible, 1.6., before the standards are 
established. A closer relationship with EUCLID projects also may be valuable. 


In summary, the Conference can be perceived as very successful. State of the art solutions as well as ideas 
and requirements for necessary future research and development were presented and the views of the 
armed forces, industry, government, and academia were discussed. The papers presented during the 
conference provided a good overview of what has been done in NATO and NATO/PfP nations, what is 
the state of the art, and the next steps. 
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Introduction 


Mr Graham G. BURROWS, Head, NUSCO 
Conference Committee Chairman 
RTA - BP 25 
92201 Neuilly sur Seine, France 


I am Graham Burrows (Head of the NATO RTA Modelling and Simulation Co-ordination 
Office). 


I have the honour and privilege to be the Chairman of the Conference Committee of this, the 
4th NATO Modelling and Simulation Group Conference. The Theme of this years 
Conference is; “C3I and Modelling and Simulation Interoperability” The importance of M&S 
has been recognised within NATO now for a number of years and among one of the key 
applications has been to provide support for military operational planning and in exercising 
and training. But key to this support has been the linking of Models and Simulations to the 
many and diverse (31 systems that we encounter within NATO and our PfP Partners so that 
we may indeed adopt the paradigm “ train as you fight” . And so the objectives of this 
Conference are to contribute to a better understanding of and an improvement in 
interoperability between M&S and (31 systems. I am sure you will find the Conference 
interesting and stimulating and worthy of the high standard and reputation that this 
Conference has engendered. Again, this year the Conference has attracted a high number of 
high quality papers — almost twice the number that we could accommodate in the time 
available. This has presented somewhat of a challenge to the Conference Committee — but I 
am pleased to say that the Committee, as always, enjoys a few challenges and this they took 
in their stride. 


I would like to thank the Conference Committee for their help and support. You will find all 
their names listed in the Programme Announcement. 

I will briefly ask the Conference Session Chairs to stand up so that the individual Presenters 
may later make contact with their Session Chairs — provide them with a CV and also make 
sure their slides have been loaded onto the main computer. So — 

Colonel Z. Ipekkan; Col. M Finnern; Mr Hans Jense; Mr Andy Fawkes; and Mr Brian 
Witherden. 


These gentlemen will also be very firm with timekeeping, and I have issued red cards to be 
flashed to any of our presenters that stray over their allotted time. 


I would also like to introduce Dr. Andreas TOLK. Andreas is a visiting professor at the USA 
Virginia Modelling, Analysis and Simulation Centre. He has been very active in M&S for 
many years and has made great contributions particularly in the Command and Control 
Systems field. Andreas has agreed to perform a very useful function at our Conference that of 
the Technical Evaluator. He will provide a critique of each of the papers, the conference 
overall and the subsequent discussion. This evaluation will be included in the Conference 
CD/Proceedings. 


Finally, I would like to offer my sincere and grateful thanks to our Turkish hosts for providing 
these excellent facilities, and their superb overall support. 


rw 
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Enjoy the Conference, in particular the Papers, please also make use of the breaks for side 
discussions, and enjoy Antalya. You are here in a beautiful part of the world at a particularly 
attractive autumn period — I hope the weather will be kind to you. 


ἽΤ RTO-MP-MSG-022: 031] & Modelling and Simulation Interoperability - Introduction 


MGANIZAT 


Host Nation Welcome Address 
(9 Oct 2003) 


Colonel Z. IPEKKAN 
Deputy chief of Turkish general staff 
Scientific Decision Support Center 
Host Nation Coordinator and NMSG TU Principal Member 
06650 Bakanliklar, Ankara, Turkey 


Commanding officer, distinguished representatives of NATO and PfP nations, good morning. 
I am Colonel Ziya IPEKKAN, Deputy Chief of Turkish General Staff Scientific Decision Support Center. 


Firstly, I would like to express my great pleasure for hosting you today and tomorrow in this beautiful city 
of Turkey for C3I and M&S Interoperability symposium 2003. Welcome you all to Antalya ! 

It is a great pleasure for me to announce to you that we are very proud to host another RTO activity during 
this week, a Lecture Series on Biological and Chemical Warfare in Istanbul which is one of the unique 
cities of the world. 


We put great emphasis on activities carried out by NATO RTO Panels/Groups and make use of every 
opportunity to take active roles in their studies. We believe that hosting such activities like this 
symposium and the lecture series in Istanbul is one of the most prominent indicators of our resolution. 
Now, I would like to give you some information on this beautiful city where we are holding this 
symposium. 

Before it came under the Ottoman sovereignty that founded in 1299, Antalya region was controlled by 
Hittites, Lydians, Persians, Seljuks and Byzantines. 

Antalya is located in the Mediterranean region, which is one of the seven regions of the republic of 
Turkey. The population of the city is around 1,5 million. Antalya is considered to be the touristic capital 
of Turkey and the east Mediterranean with its all year long sunny skies, unique natural beauties, 
magnificent beaches lapped by clear blue waters and historical wealth. This city is located on such a rare 
geography of the earth that it is possible to ski and swim on the same day. 

After this brief information on Antalya and its history, I would like to touch on a couple of points about 
Turkish armed force’s view about modelling and simulation domain. Brigadier General PEKAR wall give 
you more detailed information on this issue shortly after this presentation. 

Due to ever increasing complexity of the operational environment and shrinking defense budgets, like 
every other nation, Turkey is being forced to act wisely in all of its activities. Within this context, the 
importance and usefulness of modelling and simulation systems has been well comprehended by Turkish 
armed forces and most of the emphasis has been put on acquiring educated personnel and developing 
suitable platforms for enhancing cooperation among Turkish armed forces, universities and industry. As a 
consequence of these efforts, the contribution of modelling and simulation systems to training, analyses 
and acquisition functional areas is increasing day by day. 


Finally, once again I would like to express our pleasure for hosting you in this unique city for the NATO 
Modelling and Simulation symposium 2003. I hope we experience a very fruitful two days. 
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Brigadier General B. Pekar 
Head of Scientific Decision Support Center of Turkish General Staff 
TR 06100 Bakanliklar, Ankara 
Turkey 


Good morning ladies and gentlemen, 


First I would like to express that it is a privilege and a great pleasure for us to host this symposium and 
the distinguished community of NATO. Welcome to you all! 


As the Head of the General Staff Scientific Decision Support Center, I would like to express my 
personal views about: 


° The importance and application areas of the modeling and simulation activities for the Turkish 
armed forces, and 
. How to improve the effectiveness and the efficiency in modeling and simulation activities, 


specifically in the common ground of NATO. 


Within the limits of the defense budget, we focus our efforts to fulfill our needs for: 

° Conducting the defense planning and management activities while keeping pace with the 
rapid developments of this information age, 

. Training our military personnel to have the ability to use all those state-of-the-art defense 
systems efficiently and effectively, and 

. Preparing the forces for every type of mission, including the NATO or United Nation’s peace 
operations in different crisis regions of the world, which the Turkish armed forces has never refrained 
from participation. 


Due to environmental and financial constraints, the activities and resources required to fulfill those 
needs have confronted with being reduced. These conditions have required the intense application of 
study-analysis-decision making process in every aspect of the defense planning and management 
activities. 

Since field experimentations and live exercises cause environmental pollution, and have a high cost, it 
becomes necessary to lessen the number of practices, and to look for different, specifically economic, 
ways of meeting needs for experimentation and training. 

At this point, modeling and simulation systems come forward as a rapid and economic tool. 

In this respect, we believe that exploiting the modeling and simulation systems is one of the primary 
requirements to conduct the activities effectively for concept development, determinating capability 
gaps, system definition to meet capability lacks, systems acquisition, personnel / unit training, 
exercises, and operations analyses within given constraints. 


Consequently, we actively participate in every NATO activities related with modeling and simulation, 
while enhancing our national assets and capabilities in this respect. 

Since 1996 when the NATO modeling and simulation group was established, Turkish armed forces 
have been steering the capabilities of the national universities and the defense industry to contribute to 
developing alternative solutions to problems encountered in defense matters. 

In this respect, the Turkish armed forces modeling and simulation seminar held nationwide in 1998 
was the first attempt in enhancing national modeling and simulation capabilities. 

More than 500 attendees from different national universities, public or private sector foundations, 
research centers, and corporations participated in that seminar. 

During 13 parallel sessions of the seminar, 58 papers were presented, 17 corporations made 
demonstrations, modeling and simulation national policy, existing and required capabilities were 
addressed. 
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As a consequence, in order to institutionalize the modeling and simulation activities related with 
personnel training, the war gaming and simulation center was founded in the Turkish armed forces war 
college in 1998. 


In this center, the main goal is to provide models and simulation systems as a tool exploited in 
personnel education and training. 


In 1999, we founded modeling and simulation laboratories in the Middle East Technical University 
and Istanbul Technical University. 
The main objectives of those laboratories are: 


. To make fundamental and applied research 

. To develop models and simulation systems for providing solution alternatives to the common 
problems of different services, 

Φ To combine the efforts and the capabilities of industry, university, and armed forces, 

° To establish organizational knowledge-base, and 

e To institutionalize the collaboration activities. 


In parallel to those activities, our universities, like the Middle East Technical University, have recently 
founded techno-cities within their campus areas. In those techno-cities, subject matter experts and 
technical professionals from different scientific / engineering disciplines and defense industry site can 
find the opportunity to exchange know-how and enhance knowledge in development programs. 

We believe that those techno-cities can provide utilities and facilities in service of the NATO 
modeling and simulation community. 


In 2000, we established the scientific decision support centers and units in the main headquarters of 
the services and the general staff in order to provide decision support to high level decision makers, 
and to coordinate modeling and simulation activities related with employment and infrastructure 
initiatives. 

In accordance with the decision support centers and units, the Turkish armed forces modeling and 
simulation coordination and consultation boards were established in order to coordinate the M&S 
efforts from the joint point of view. 

During the last five years, postgraduate studies related with M&S in different national and 
international universities have been provided to more than 100 personnel and those personnel were 
assigned to the posts in accordance with their academic backgrounds. 

In cooperation with Turkish armed forces, the Middle East technical University started a postgraduate 
program specifically in modeling and simulation. The scholars have chance to make their researches 
and thesis studies in the modeling and simulation research and application center in the same campus. 
We believe that this postgraduate program can serve for the needs of the NATO nations as well. 

There are also defense institutes in our army, navy, and air force academies for officers to make 
scientific, fundamental and applied research. 

Turkish armed forces also makes contributions to the efforts of NATO studies, analysis, and 
simulation panel. Recently there were two working groups lead by Turkey in the NATO SAS Panel. 
While enhancing the modeling and simulation capabilities in parallel to the developments in M&S 
domain, it is also necessary to spend effort to disseminate those capabilities among the services and 
personnel in the application domain. 

We believe that the accreditation, verification and validation activities for models, simulation systems, 
and certification of data used in M&S applications are the essential driver efforts for M&S to be 
accepted and exploited by the M&S user communities throughout the armed forces. Our efforts in this 
respect are still ongoing. 

Canada and Turkey have been collaborating in the M&S through the NATO fellowship program, 
which has been actively used for at least 15 years. We have been observing that these kinds of 
collaborations also serve in establishing a common M&S culture and in exchanging M&S knowledge 
between nations. We strongly recommend that other NATO nations participate in and provide NATO 
fellowship programs among each other. 
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We also believe that various research centers in NATO countries can be guided by the NATO MSG to 
establish cooperation between them with respect to the needs of NATO. We consider that our 
establishments are ready and eager to take place in such collaboration. 


In the light of the global changes and developments, the theme of the symposium, which is “C3I and 
Modeling and Simulation Interoperability“, has a particular significance among all others. 

Modeling and simulation systems used in redefining new threats, which has been uncertain as a 
consequence of 9/11, and in determining new operations forms against that new threat, should 
certainly cover command and control matters with a required level of detail. 

Thus, we believe that the interoperability between C3I models and other simulation systems is one of 
the indispensable requirements for new system developments. 

During this symposium, four different papers will be presented by Turkish authors. Those papers will 
address the findings and issues that come out from development and research projects about modeling 
and simulation of operation command centers, modeling of border security and control systems, 
graphical interface software developments for war games, and modeling command and control. Those 
four development and research projects were conducted with the cooperation of industry, university 
and the Turkish armed forces. 

It is certain that NATO nations will have a chance to share their knowledge and experience on M&S 
during this symposium. We believe that this invaluable activity will provide the opportunity to 
exchange information that can help us avoiding duplication of efforts, and determining the issues we 
should focus and / or aggregate our efforts on. 

For organizing this invaluable symposium, I would like to thank the NATO Modeling and Simulation 
Group, which carry the burden and the responsibility of guidance and coordination in use and 
enhancement of M&S technologies among NATO nations. 


Finally, once again I would like to express our pleasure for being the host nation of the 2003 NATO 
Modeling and Simulation Symposium, to say “welcome you all in Turkey”, and I wish you all have a 


good time and enjoy your stay in Antalya. 


Thank you. 
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OVERVIEW 


The Simulation Interoperability Standards Organization (SISO), in particular the Planning and Review 
Panel (PRP) on Command, Control, Communications, Computers, and Intelligence (( 41), deals 
intensively with the topic of M&S and C3IInteroperability over the recent Simulation Interoperability 
Workshops (SIW) which are taking place in the Spring and in the Fall every year in the United States. 
Since 2001, a European SIW also occurs every summer in Europe in various places. 


The SISO C4I Forum addresses primarily the modelling and simulation of Command, Control, 
Communications, Computers, and Intelligence (C4I) systems in constructive, virtual, and live 
environments, the coupling of real C3Isystems and simulation systems for computer assisted exercises 
(CAX), and support for operations. Additional focus: Development of a Command, Control, 
Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) Technical 
Reference Model (TRM), a common framework for C4ISR system-to-simulation interoperability, and 
relationships among international C4ISR architectures. It sponsored two study groups, namely the Study 
Group on “C4I Study Group” (March 1999 — September 2000) and the Study Group on 
“C4ISR/Simulation Technical Reference Model Study Group” (March 2001 — September 2002), which 
results and related underlying, parallel, and future papers will be presented within this paper. The second 
Study Group will present the results of additional work during the SIW in Fall 2003, among others in form 
of a “C4ISR/Simulation Interoperability Source Book.” 


1 INTRODUCTION 


The Simulation Interoperability Standards Organization (SISO) is dedicated to the promotion of modelling 
and simulation interoperability and reuse for the benefit of diverse M&S communities, including 
developers, procurers, and users, world-wide. SISO originated over ten years ago. The initial conferences 
rapidly on general simulation interoperability evolved into the Distributed Interactive Simulation (DIS) 
Workshops. The DIS Workshops transformed in 1996 into a more functional organization called SISO 
participating actively in the standardization efforts related to the High Level Architecture (HLA). Today, 
SISO is concerned with all sorts of standard development and application facilitating interoperability 
between simulation systems as well as between simulation systems and real life systems. 


SISO actually conducts three workshops per year, called the Simulation Interoperability Workshops 


(SIW). Two SIW are conducted in the United States, the Spring SIW and the Fall SIW. In addition, one 
European SIW is conducted in summer. 
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The scope of the Workshop encompasses a broad range of simulation issues and communities, including 
military applications as well as other government and non-government applications. Workshop 
participants include simulation developers, simulation users, and operations analysts, from various 
government, industry, and academic communities. The Workshop focuses on issues involving distributed 
interoperable and composable simulations, reusable components, and on the development of a common 
process model for designing, composing, executing, and analysing the results of simulations, as articulated 
in the High Level Architecture (HLA) for Modelling and Simulation. While HLA is definitely a 
cornerstone of SISO and SIW activities, the actual scope is broadening and new technologies supporting 
concepts of advanced distributed simulation are evaluated increasingly. 


The SIW include tutorials, papers on state-of-the-art experiences, identification and discussion of 
interoperability issues, and presentation of proposed solutions. As these solutions are prototyped and 
demonstrated, they become candidates for possible standards within relevant simulation communities. 
Various workshop forums provide opportunities for user and technical communities to meet, share ideas 
and experiences, identify ways to make distributed simulation more effective and efficient, and support the 
development of appropriate interoperability standards. Of particular interest for the conference on “C3I 
and M&S Interoperability” is the forum on “Command, Control, Communications, Computers, and 
Intelligence (( 4." 


The C4I forum addresses standards to ensure interoperability when coupling simulation systems and 
C3Isystems, standards to ensure composability when integrating simulation components and 
C3Icomponents into a common framework, and standards to represent C3Isystems and the underlying 
infrastructure within simulation applications. Within this forum, papers are presented which are dealing 
with architecture and data/object model alignment, common frameworks, applicability of C3Istandards 
and open standards, and lessons learned from applying these standards. In particular, C3Isupports the 
development of enhanced operational functionality based on M&S, and especially on increasing the 
efficiency and abilities of the Warfighter by introducing simulation capabilities within operational 
systems. 


The C4I forum sponsored two Study Groups dealing with interoperability of command and control 
systems and simulation systems. The role of a SISO Study Group is to prepare a domain for future 
standardization. To this end, the scope of the future standard has to be defined, time lines for perceived 
achievements are established, literature researches are done and evaluated, related SISO papers are 
analysed, and respective reports and supporting documentation are produced and disseminated. When 
successful and advanced enough, a Product Development Group will take up the work to establish a 
proposal for a new standard to enhance interoperability for simulation systems and live systems as 
envisioned in the SISO charter. 


The first Study Group dealing with the general problem of command and control system to simulation 
system interoperability was called “C4I Study Group” and was conducted from March 1999 to September 
2000. The second Study Group was called “C4ISR/Simulation Technical Reference Model Study Group” 
and started in March 2001. The final report of this second group was delivers in September 2002; 
however, it was also perceived that much more work needed to be done before a Product Development 
Group could be established. Therefore, the Study Group members decided to work on additional follow- 
on products under the aegis of the C4I forum. The next report will be delivered during the Fall STW 2003 
to be conducted in September 2003 in Orlando, Florida, United States. 


The author chaired the C4I forum of SISO during this period. Furthermore, he contributed actively to the 
resulting reports. He also published several papers dealing with this issue, some of them having been 
awarded by SISO. 


However, this paper gives his personal view on the problem domain and the achievements of the resulting 
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reports of the Study Groups. The findings in these papers are therefore individual interpretations, and 
neither do they reflect the official view of the Virginia Modeling Analysis and Simulation Center, nor the 
view of the SISO or any sponsors of the related efforts. 


2 DEFINITION OF THE UNDERLYING PROBLEM 


The NATO Modelling & Simulation Master Plan (NMSMP) [1] defines various domains of simulation 
system applications, which implicitly demand the integration of simulation systems into command and 
control systems or vice versa, e.g., to conduct computer assisted exercises (CAX) and to deliver simulation 
based support to operations. Interoperability of these two families of systems is furthermore necessary to 
reach the Objectives and Subobjectives of the NMSP, as stated in table 1. 


Table 1: Objectives and Subobjectives in the NATO Modelling & Simulation Master Plan 


Objective 1 Objective 2 Objective 3 Objective 4 Objective 5 
Establish a Provide Common Develop Employ Incorporate 
Common Services in NATO Simulations Simulations Technical 
Technical M&S Advances 

Framework 
1.1 Adopt HLA 2.1 Compile 3.1 Identify & 4.1 Plan 5.1 Monitor 
M&S Prioritise Employment M&S related 
Information Requirements Advances 
1.2 Establish 2.2 Provide M&S | 3.2 Identify 4.2 Provide 5.2 Conduct 
Data Education Strategies Resources Research & 
Interchange Development 
Standards 
2.3 Establish a 3.3 Allocate 4.3 Provide 5.3 Share 
Simulation Resources Databases Information 
Resource 
Library 
2.4 Establish a 3.4 Execute 4.4 Operate 5.4 Implement 
Help Desk Strategy Simulations Advances 
3.5 Provide 4.5 Conduct 
Feedback Impact 
Assessment 


As stated in [2], one of the shortcomings of the NMSG is that he is not connected, aligned, or harmonized 
with the NATO Consultation, Command and Control (C3) Technical Architecture (NC3TA) [3]; neither is 
the NMSG integrated into the NC3TA. 


In other words: Both communities — C3I and M&S -- are using the same or very similar information 


technology (IT) and the same commercially driven solutions for underlying operations, such as filing, 
networking, messaging, databases, etc.; however, the applications of both communities have been 
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developed in a stove-piped manner without knowledge of the other sides efforts (and often not even with 
the knowledge of the efforts of the same community). Unfortunately, as the discussions with the 
participants in the Study Groups showed, this observation is true all over the world, last but not least in 
leading countries of NATO, such as the France, Germany, the United Kingdome, and the United States. 


The result is generally an interface driven solution, such as categorized in [4]. Most of these interfaces are 
based on ad-hoc efforts, leading to rigid information infrastructures, double efforts, the permanent 
reinvention of the wheels, and systems with interfaces as much as potential partners. This solution is not 
satisfying. Consequently, alternative approaches were proposed since several SIW. They can be divided 
into three broad categories: 


— The first group is primarily focussed on the coupling of command and control systems with 
simulation systems based on the idea of standardized interfaces, or at least common reference 
models to be used for the development of these interfaces. 


— The second group tries to reuse more or less already established and/or standardized components 
and solutions to enhance C3]-to-M&S Interoperability. These components are primarily found in 
the (91 domain, such as Common Message Providers, or data models used for automatic database 
replication mechanisms. 


— The third group is interested in setting up a common infrastructure for military IT to be used by 
the C3I community as well as the military M&S community. In particular the use of common 
commercial solutions, open standards, or even open sources could facilitate this objective, which 
needs to comprise migration concepts for legacy applications in order to become a viable option. 


SISO deals with all three aspects, and in the Study Group reports and among the additional SIW papers, 
candidates of all three categories can be found. To decide which is the most promising solution would be 
premature, although the author definitely prefers the option of a common infrastructure. However, to 
reach this long-term goal, working interface solutions will be necessary to proof the feasibility and 
demonstrate the operational usefulness are necessary, and the work being done in this category may be 
reused for migration solutions later. The use of C3I components is also just a step to a common 
infrastructure, as it only makes sense to use C3I components if they are efficient enough to use them in the 
M&S context, i.e., if it makes sense to reuse them. 


To summarize the underlying problem it can be stated, that standards are needed to bridge the gap between 
legacy systems as well as standards to avoid stovepipe like developed systems in the future. In addition, 
migration procedures are necessary to transform valuable legacy applications for future use. 


While the final report of the “C4I Study Group” (March 1999 — September 2000) [5] framed the problem 
and identified valuable approaches, the final report of the Study Group on “C4ISR/Simulation Technical 
Reference Model Study Group” (March 2001 — September 2002) [6] started to focus on standardizable 
framework concepts. In addition, a C4ISR/Sim Technical Reference Model Sourcebook [7] as well as a 
User Guide to the C4ISR/Sim Technical Reference Model [8] were initiated to deliver additional guidance 
for potential users. These two last documents will be presented during the Fall 2003 SIW. 


3. THE C4ISTUDY GROUP 


In order to assess “where we are and where we need to go,” SISO charted an M&S-to-C4I Interoperability 
Study Group to: 


— Provide background and current information on C4ISR and simulation interoperability efforts; 
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— Provide a standards-based assessment of past and current interoperability efforts; and 
— Make recommendations on how the SIW C4I Forum should proceed with standards development 
activities. 


99 66. 55 66. 


The final report of this Study Group [5] discusses “where we have been,” “where are we now,” “where we 
should go,” and “how do we get there.” While the authors of this report have collated submissions and 
edited this report, in truth it is the result of more than a dozen direct contributions in the form of draft 
sections and the indirect contributions of the more than one hundred subscribers to the SG-C4I reflector. 


The main reason for setting up a study group was user requirement driven, i.e., derived from necessities to 
support preparing and conducting future military operations. Simulation interfaces to Command, Control, 
Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) systems are 
essential to support: 


— Simulation Based Acquisition (SBA); 

— Development of Doctrine, Tactics, Techniques, and Procedures (DTTP); 
— “Train as you fight,” in particular Computer Assisted Exercises (CAX); 
— Embedded Training (both individual and collective); 

— Course of Action Development and Analysis; 

— Mission Planning and Rehearsal; and 

— Execution Monitoring. 


To satisfy the Study Groups goals, this report comprises: 


— Background and current information on C4ISR and Simulation Interoperability efforts; 

— A standards-based assessment of past and current interoperability efforts; and 

— Recommendations on how the Simulation Interoperability Workshop (SIW) C4I Forum should 
proceed with M&S-to-C4I interoperability related standards development. 


3.1 Message oriented Approaches 


An overview of previous attempts to couple M&S and C3] systems establishes the basis for the assessment 
and the recommendations in the final report. As the contributors to the report mainly gained their 
experience in the United States, the majority of the examples are from U.S. systems. However, some 
examples from the NATO environment are given as well. The first approaches used C3I messages to 
couple command and control and simulation systems. Mainly to support CAX, simulation systems were 
used to create tactically meaningful and adequate text messages, e.g., in ADatP-3, OTH Gold or USMTF 
format.' The link between the Tactical Simulation (TACSIM) to the U.S. Automated Defence Information 
Network (AUTODIN) message system in support of the Tactical Exploitation of National Capabilities 
(TENCAP) program in 1980 is an early example of such efforts. Another example given in the report is 
the link of TACSIM to the Korea Combat Support System (KCSS) and the Korea Air Intelligence System 
(KAIS) for key intelligence message traffic. KCSS and KAIS were the primary C3I systems that 
supported the Air Component Command (ACC) of the Korean Combined Forces Command (CFC). 
During this same event, there was a linkage developed and implemented between the Air Warfare 
Simulation (AWSIM) and Tactical Receive Equipment (TRE)/Tactical Related Applications (TRAP) 
systems. From TRAP, the information was fed through a TENCAP project component known as the Air 
Defence Systems Integrator (ADSI). This allowed enemy aircraft tracking data to be input to the air 
defence cell at the Control and Report Centre (CRC). In this way, there was established a direct linkage of 


' ADatP = Allied Data Publication; OTH = Over the Horizon; USMTF = United States Message Text Format. 
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simulation data to major operations and intelligence centres, including the intelligence I&W centres, 
Electronic Combat Centre, Control and Report Centre, and Combat Operations. 


Of particular interest could be the example of the Warrior Preparation Centre (WPC), a U.S. facility for 
Command Post Exercise (CPX) support in Germany. In 1994, the WPC built a two-way interface between 
AWSIM to the Contingency Theatre Automated Planning System (CTAPS). The objective of the effort, 
known as Project Real Warrior (PRW), was to maintain the existing simulation to C4ISR interfaces, 
expanded those where possible, and to establish a database link from the CTAPS to AWSIM. The 
primary motivation behind this effort was the reduction of manpower within the exercise response cells by 
providing an automated entry of the Air Tasking Order (ATO) into AWSIM. Since the ATO can contain 
upwards of 2000 missions per day, this offered a significant reduction in manpower requirements. These 
systems were used for later NATO exercises as well and many lessons learned were derived for NATO 
efforts in the CAX area. 


These early efforts influenced the development of the Modular Reconfigurable C4ISR Interface (MRCI) 
[10], which attempted to develop a standardized data output stream from a simulation to C3I systems and 
to incorporate a standardized method for converting C3I system inputs to the simulations. This effort was 
initially supported by DMSO and later by the Defence Advanced Research Project Agency (DARPA). 
MRCI was demonstrated during the Synthetic Theatre of War (STOW) 1998 experiment. While many 
aspects of the MRCI experiment were similar to earlier efforts in C4ISR to simulation interoperability, 
there were two unique features: 


— The attempt to develop a standard interface to the C4ISR environment, in contrast to previous 
efforts, which in general created unique interfaces to each C4ISR system. 

— The attempt to develop and mature a technology for translating command and control directives 
(or commands) into simulation “orders.” 


For the second feature, a tool known as the Command and Control to Simulation Interface Language 
(CCSIL) was developed. However, although MRCI, and in particular CCSIL, were applied several times, 
they never became widely accepted in any of the two communities. 


Additional information on more U.S. efforts, NATO efforts, and national efforts is given in the report [5]. 
Furthermore, the Long Term Scientific Study on CAX [9] conducted on behalf of the NATO Research 
and Technology Organization (RTO) Panel on Studies, Analysis and Simulation (SAS) gives some 
examples as well. In addition to the CPX level efforts described here in some detail, there have been a 
number of efforts to develop these interfaces at the entity, and even the engineering level, which are not 
covered in this overview. Furthermore, the use of binary messages, such as Link-16 or the Tactical Digital 
Information Link (TADIL) family, is an issue not further dealt with in this paper, but you can find 
paragraphs dealing with examples in the final report of the Study Group. 


The main idea of all message driven efforts is the use of the same messages that are used for the 
information exchange between command and control system. The main advantage of this approach is, that 
the command and control systems haven’t to be changed. The main disadvantage is that the information 
to be exchanged between C3I and M&S is limited to the message content, and simulation issues normally 
did not contribute to the definition of these information exchange requirements. 


3.2 High Level Architecture driven Approaches 


The use of the High Level Architecture (HLA) for M&S systems is a central point in the United States 
DoD Modelling & Simulation Master Plan [11] as well as in the NATO Modelling & Simulation Master 
Plan [12]. In late 1994 and early 1995, the Defence Modelling and Simulation Office (DMSO) conducted 
a baseline assessment of all DoD M&S. From this assessment, DMSO published in the first U.S. DoD 
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M&S Master Plan in October 1995. This plan established the HLA as a central component of the DoD 
M&S Technical Framework. 


Taking the U.S. DoD M&S Master Plan as one input, in November 1996, NATO began to develop a 
NATO M&S Master Plan. The Conference of National Armaments Directors (CNAD) established a 
Steering Group on NATO Simulation Policy and Applications with a mandate to craft an Alliance 
approach to simulation in order to improve Alliance operations. The resulting NATO M&S Master Plan 
establishes a co-operative approach for applying advanced simulation techniques to aid in satisfying the 
needs of the NATO Alliance and its member nations. It is assumed that successful execution of the master 
plan will promote the aim of Alliance-wide simulation interoperability and reuse, while also providing 
national and NATO bodies with significant modelling and simulation interest, with the necessary latitude 
to meet their specific needs. Again, the High Level Architecture plays a central role. 


Consequently, C3I to M&S approaches used the concepts introduced by the HLA, in particular the idea to 
use standardized Reference Federation Object Models (FOM).’ In the following, some examples are given 
that were used by the Study Group. All FOMs are included in the library that have been developed by the 
Study Group and can be downloaded from the SISO website. 


The Prototype C4I FOM is the result of a U.S. Army requirement to develop a common environment to 
facilitate the use of constructive, virtual, and live simulations in the evaluation of C3Isystems in the 
Research, Development, and Acquisition (RDA), the Advanced Concepts and Requirements (ACR), and 
the Training, Exercises, and Military Operations (TEMO) domains. To be effective, the simulation 
environment must be capable of interoperating with real C3Isystems in a manner that is flexible, 
extensible, and promotes re-use of software components. The prototype C4I FOM is a step toward 
providing this capability by providing a standardized representation for interoperability that can be applied 
to a variety of C3Isystems. 


The Naval Research Laboratory is developing a C4ISR FOM for DII COE based C4ISR systems under the 
sponsorship of DMSO and DISA. The C4I Ambassador software provides two-way links between the 
embedded RTI and the DII COE Services, databases and C4ISR Mission Applications. It interprets the 
FOM (parses and reformats data as necessary) and manages simulated data distribution within C4ISR. 
This development builds on the technology contained within the recently released Global Command and 
Control System (GCCS) Embedded Training Segments for inserting training data into operational GCCS 
systems. 


The Study Report also includes sections on additional FOMs, among others the U.S. Joint Forces 
Command J6 NETWARS FOM, and shows potential for alignment. The principals, however, are the 
same among these approaches. 


The main idea of these FOM driven approaches is to capture the aligned information exchange 
requirements using the format of the High Level Architecture Object Model Template. The main 
advantage of this approach is that HLA compliant systems can easily use this information. The main 
disadvantage is that the command and control systems’ interfaces have to be adapted to the needs of HLA. 


3.3. The Vision of the (41 Study Group 


It would go beyond the scope of the overview of the final report of the first Study Group to deal with 
every detail. To be able to cope with the vision, however, it is necessary to know that various architecture 
concepts were evaluated as well. In particular their contributions to interoperability of C3I and M&S were 


2 Tt is assumed that the reader is familiar with the High Level Architecture; therefore, the concepts are not introduced in this 
paper. 
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an issue. To the evaluated architectural concepts belong the High Level Architecture (HLA), the Joint 
Technical Architecture (JTA), the U.S. Defence Information System Agency (DISA) defined Common 
Operational Environment (COE), and the NATO C3 Technical Architecture (NC3TA). Furthermore, 
various existing federations are described in the final report to complete the state of the art section. Based 
on the findings, the in the following paragraphs summarized vision was formulated. 


“Where we are now and where we need to go.”’ 
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Figure 1: Vision for the Way ahead (C4I Study Group, 2000) 


The roadmap for improving the interoperability between simulations and C3Isystems is shown in Figure 1. 
For the near term, the vision depicts the currently predominant architectures in use for M&S-to-C31 
interfaces. Such interfaces are mostly custom “point-to-point” links that are often “black box” in nature. 
Simulation control is basically one-way, with the simulations initialising the real C4ISR system databases. 
In the mid term, it is expected to see the HLA linking constructive and virtual simulations on the 
simulation side and, on the “real” side, the HLA, via common components found in C3I systems (e.g., 
components of the U.S./NATO Common Operational Environment, such as common message processors) 
also allowing C3I systems to exchange both data and messages with simulations. Simulation initialisation 
will be two-way, with real system databases providing information to the simulation side. Ultimately, as 
shown as “Far Term,” a have full two-way linkages via common databases will be achieved, thus 
achieving a higher measure of interoperability. The vision articulates only a broad vision of where M&S- 
to-C3I interoperability needs migrate to go over time. The Far Term is not an end state, but is where we 
could be in 2010 to 2012, if the M&S and C4ISR communities articulate their joint requirements and 
develop coordinated architectures and standards. 


The final report of the Study Group was delivered in September 2000. Many of the mid-term prediction 
became reality, such is the growing establishment of HLA enriched by completing open standards, 
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although the overall speed of the process has been overestimated, as we are overall moving slower then 
expected (or maybe hoped for) by the expert group. 


4 THE C4ISR/SIMULATION TECHNICAL REFERENCE MODEL STUDY 
GROUP 


The “Report Out of the C4I Study Group” [5] presented during the Fall 2000 SIW called for a standard 
frame of reference, in the form of a Command, Control, Communications, Computer, Intelligence, 
Surveillance, and Reconnaissance (C4ISR)/SIM Technical Reference Model (TRM), for interoperability 
between command and control and simulation systems. The C4ISR/Sim TRM defines methods and levels 
of interoperability of systems or classes of systems. The report also cited the need for the C4ISR/SIM 
TRM to include a broad data class, Metadata; and requested consideration of how the C4ISR/Sim TRM 
would relate to other interoperability models in a follow-on study to determine the desirability of 
integrating the C4ISR/Sim TRM and other interoperability models such as the DoD Level of Information 
Systems Interoperability (LISI) model, the NATO interoperability model, and other national and 
international interoperability models. Accordingly, the C4I Study Group (SG) recommended the 
formation of a follow-on C4ISR/Sim TRM SG to develop a C4ISR/Sim TRM, leveraging existing work; 
and foster development of that TRM into a formal SISO product. The resulting C4ISR/Sim TRM Study 
Group worked together for 22 months, including various meetings during the SIWs as well as 
teleconferences and email exchange. The Study Group consisted of international experts in this domain, 
however, as before the main interest lay within the United States. The final report [6] was presented 
during the Fall 2002 SIW and summarizes the efforts of the C4ISR/Sim TRM SG, and provides 
recommendations for continued development of the TRM. 


The C4ISR/Sim TRM SG was formed to create a standard frame of reference for interoperability between 
C4ISR Systems and M&S systems. The C4ISR/Sim TRM is intended to be used to describe as well as 
categorize the interoperability of systems or classes of systems. It is a technical model that can be used to 
measure the level of interoperability of systems or classes of systems. By design, the TRM facilitates 
analysis of requirements, architecture, design, implementation, and testing of heterogeneous systems. In 
addition, the TRM is expected to support improved dialogue among users, developers, and technicians in 
the C4ISR community. 


The Study Group realized, that a unified model in form of a single reference model might be difficult to 
achieve. Therefore, another approach has also been proposed for study by the Study Group: Instead of 
establishing a new model, existing and established models could be fused as complementing views on the 
unifying reference architecture. This solution is coherent with solutions proposed in the U.S. DoD C4ISR 
Architecture Framework [13], the NATO C3 System Architecture Framework [14], the Joint Technical 
Architecture [15] approach, and furthermore reflects the interoperability solutions being used in the 
commercial branches of information technology. Although the final report of the second Study Group 
doesn’t make recommendations how the framework should look like (this is done in the follow-on work, 
see [7]), it identifies the relevant reference architectures in more detail — and adds some new — than this 
was the case in the initial collection used in the report of the first Study Group. 


41 Existing C3I to M&S Interoperability Technical Reference Models 


The first TRM to be mentioned is the “House Diagram,” which has been developed by Michael Hieb and 
Andreas Tolk to facilitate the discussions within the STW C4I forum. It was picked up by various authors 
and proofed to be a valuable although simple way to structure the various interoperability domains. In 
summary, the “House Diagram” blueprints the complexity of interfacing simulation systems and command 
and control systems. This holistic view emphasizes the interdependency of five major factors involved in 
the effort to secure shared solutions for C3I/M&S interoperability: Architectures Alignment, Common 
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Data/Object Models, Common Standards, Alignment Processes, and Reusable Component Interfaces. 


Interoperability of legacy 


And future Systems 


Reusable Component 
Interfaces 


Processes 
For Common Common 
Alignment Standards Data/Object 
and & Tools Models 
Migration 


Alignment of 
Architectures 


Figure 2: The "House Slide" on Interoperability 


Architecture Alignment recognizes the fundamental necessity to align the framework architectures for both 
M&S and C3I domains. As already pointed out earlier, the U.S. DoD C4ISR community has developed 
the Defence Information Infrastructure Common Operating Environment (COE). NATO is using the 
NATO Technical Architecture Model (NC3TA), including the NATO COE. The M&S community has 
established the HLA. These constructs establish the foundations that set the requirements for fundamental 
interoperability between components of these two domains. The architecture alignment needs to be able 
to resolve differences in viewpoints or fundamental representation of the problem space. 


Within the M&S domain, the HLA Federation Object Model (FOM) methodology is used to align Data 
Models and Object Models among M&S federates. While this methodology works, it places a heavy 
burden on developers. When extending beyond the M&S domain into the C3I domain, temporary 
(situational) alignment presents additional challenges: synchronizing development cycles, aligning domain 
ontology, and coordinating data standards. These constraints normally resolve into the need for a data 
translation layer between C3I and simulation domains. However, this gateway strategy can exact a major 
performance penalty. If systems are aligned to the same or similar object model or data model 
representations, performance increases as translation penalties and FOM alignment burdens decrease. 


Common Standards are most effective when they are part of the system design. Integration of standards 


begins with the framework architecture for each domain and extends through the support for common 
objects and data models. To this end, C3I and M&S systems should be designed initially for 
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interoperability. 


Reusable Component Interfaces sit on top, and therefore rest upon, the building blocks below. However, 
when compared to architectures, models, or standards, interfaces have been a hotbed of activity. This 
apparent paradox stems from our ability to partition the problem space at the interface and thus provide 
short-term solutions for quick success. However, in general these solutions are too shallow, one has to 
pay and pay again for these unique interfaces in terms of costs, time, and flexibility. If realignment of the 
underlying structures eliminates basic incompatibilities between the systems and a wealth of benefits 
ensues. 


Finally, the roof of the house diagram envisions Shared Solutions between C3I and Simulations. This 
aspiration must be supported by all of the underlying blocks. In addition, it requires that the systems align 
or translate inherent processes. For example, terrain alignment and object placement must be consistent 
between components in both domains. 


The second TRM evaluated in the final report of the C4ISR/Sim TRM Study Group is the C4ISR/Sim 
Technical Reference Model for Interoperability as introduced by Carr and Hieb in [16]. The C4ISR/SIM 
Interoperability TRM identifies data types exchanged between C3Jand M&S systems. Systems engineers 
identify data requirements and code interfaces to handle information exchanges between C3I and M&S 
systems. Generalizing these efforts, one can document and classify information that an interface must 
handle. The C4ISR/Sim Technical Reference Model for Interoperability builds the basis for the follow-on 
efforts dealt with in the next section.’ Therefore, we will not discuss this TRM at this point. 


The third TRM has been introduced by Ressler, Hieb, and Sudnikovich [17]. They describe a reference 
model focused on the information exchange activities between C4ISR and M&S components. They 
suggest a conceptual reference model based on the decomposition of processes for exchanging data 
between C4ISR and M&S systems. Their Information Exchange Activity Model forms a central 
component of a generalized C4ISR/Sim conceptual reference model. This Information Exchange Activity 
Model captures activities essential to establishing interoperability between domains. 


To cope with the aspects of architecture alignment as proposed in the “House Slide,” Furness, Carr, and 
Hieb introduced the fourth TRM, the General Unified Model (GUM) for M&S to C3I interoperability 
[18]. This high level model divides both architectures of the M&S and C31 families into four categories 
providing the ability to accommodate functions present in any representative implementation. A 
reasonable set of the common functions of both C4ISR systems and M&S systems provide the starting 
point for the GUM. The resulting candidate set of common functions comprises User Interfaces, 
Management and Execution, Data, and Algorithms. This list is neither complete nor exclusive, but helps 
to structure the architectural domains that have to be interoperable for a given purpose. 


A lot of work being presented within recent SIW are relevant to this effort as well and has to be taken into 
account although not directly connected to a reference model. The topics of meta data, meta modelling 
and the problem of data alignment have to be stressed in this context. The new role of data engineering 
emerged from respective findings. Within actual solutions of C4ISR and M&S system coupling, the 
system designer tasked with the integration has to know what data is located where, the meaning of data 
and its context, and into what format the data have to be transformed to be used in respective distributed 
applications within the overall system. Data Engineering is coordination the efforts of the sub-tasks of 
data administration, data management, data alignment, and data transformation. The first three can be 
standardized and used in a general manner. Only the task of transforming the data really is system 
dependent, and it has been shown that even for this task a general solution exists. 


᾿ Furthermore, Carr presents during this NATO Symposium his recent findings and recommendations in Paper No. 18 within 
this proceedings. 
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- Data Administration is the process of managing the information exchange needs that exist within 
a group of systems, including the documentation of the source, the format, context of validity, and 
fidelity and credibility of the data. Data Administration therefore is part of the overall information 
management process. 


— Data Management is planning, organizing and managing of data by defining and using rules, 
methods, tools and respective resources to identify, clarify, define and standardize the meaning of 
data as of their relations. 


— Data Alignment ensures that the data to be exchanged exist in the participating systems as an 
information entity or that the necessary information can be derived from the data available, e.g., 
using the means of aggregation or disaggregation. 


— Data Transformation is the technical process — often implemented by respective algorithms within 
the gateways and interfaces — of aggregation and/or disaggregation of the information entities of 
the embedding systems to match the information exchange requirements including the adjustment 
of the data formats as needed. 


Most actual works are focusing on data transformation, i.e., the programming or maintenance of 
interfaces. However, if such efforts are not accompanied by an alignment of the respective management 
processes for data administration, management, and alignment, the result is in the best case a temporary 
valid solution that is effective until the next update of one of the participating systems. Consequently, the 
managing processes of the participating systems must at least be harmonized. In the ideal case, the 
program managers will even use the same methods and supporting tools to do so under a common, 
overarching approach as already proposed by the House Slide in an earlier section. 


4.2 Relevant Reference Models from C3I and Commercial Information Technology 


In addition to the existing C3I to M&S interoperability TRM, relevant reference models not only from the 
(31 community, but also from the commercial IT world were evaluated. For the complete evaluation, the 
interested reader is referred to the final report. In this overview, we will just mention the models and deal 
with the two that played a central role in the Study Group, namely the Level of Information Systems 
Interoperability (LISD [19] and the NC3TA Model of Interoperability (NMJ) [3]. 


The LISI model provides a reasonable framework to scope the needed level of connectivity in the domain 
of technical interoperability. LISI is established by the U.S. DoD C4SIR Framework Architecture [13]. 
LISI identifies four domains, namely Procedures and Policy, Applications, Infrastructure, and Data 
(PAID). Every one of the PAID domain impacts on information exchange, in other words, a level of 
interoperability exists within each of the PAID domains. The resulting technical interoperability is 
measured in five categories: 


Level 0: Isolated (Manual) — Non-connected, use of manual gateways (diskettes, etc.) 


— Level 1: Connected (Peer-to-Peer) — Electronic connection; Separate data and applications 


Level 2: Functional (Distributed) — Minimal common Functions; Separate data and applications 


— Level 3: Domain (Integrated) — Shared data; “Separate” applications 


Level 4: Enterprise (Universal) — Interactive manipulation; Shared Data and applications 


Level 4 is the highest level of technical interoperability, i.e., data is electronically delivered to the 
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Warfighter regardless what access method he uses (from handheld to C3I workstations) and from where he 
uses this device. He can just plug into the infosphere and can use all applications, wherever he is and 
wherever the applications are. 
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Figure 3: The LISI Model 


NATO is using a very similar model to LISI. It is comprised in the NATO C3 Technical Architecture 
(NC3TA) [3]. The NC3TA describes the IT architecture to be used as a basis for interoperable NATO 
systems. It addresses architectural descriptions, reference models, and Off-The-Shelf (OTS)-technologies. 
Furthermore, the NC3TA integrates technical aspects of specific architectures or frameworks such as the 
NATO Information Security Framework. The NC3TA consists of five volumes dealing with 
Management, Architectural Models and Description, Base Standards and Profiles, NC3 Common 
Standards Profiles (CSP), and the NC3 Common Operating Environment (COE). The NC3TA contains 
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five technical reference models of interest to our review of C4ISR/M&S interoperability: 


The NC3TA Technical Reference Model (NTRM) provides the conceptual framework and 
common vocabulary for addressing interoperability and compatibility among NATO information 
systems. It sets a foundation for all NC3 technical architectures. 


The NATO Common Operating Environment (NCOE) Component Model (NCM) instantiates the 
NTRM and models the NCOE architecture. In turn, the NCOE aspires to define a plug and play 
client/server environment [Volume 5] to increase interoperability, reusability, portability, and 
operational capability while reducing development time, technical obsolescence, training 
requirements, and life cycle cost. 


The NATO-Common-Funded (NCF) Reference Models for Functional Configurations (NFC) 
refines the NCM. This set of reference models provides functional configurations as building 
blocks for developing the functional architecture of NCF systems. 


The NATO Reference Model for Open Systems Information Interchange (NOSI) focuses on 
communications issues not covered by previous models. 


The NC3TA Reference Model for Interoperability (NMI) models technical interoperability by 
leveraging the concept of degrees of interoperability. Categories of elementary services form a 
descriptive basis for functional interoperability profiles. 


The NC3TA reference model for interoperability (NMI) establishes interoperability degrees and sub- 


degrees. 


Interoperability degrees define a maturity model that captures interoperability sophistication. 


Interoperability sub-degrees describe a capability model that reflects available functionality. These 
degrees highlight the value of structuring and automating exchange and interpretation of data to enhance 
operational effectiveness. The NMI provides definitions for interoperability degrees and sub-degrees and 
presents interoperability profiles. The NMI classifies interoperability at four levels. 


Degree 1: Unstructured Data Exchange 

This level involves the exchange of human-interpretable, unstructured data such as the free text 
found in operational estimates, analysis, and papers. Sub-degrees are Network Connectivity, 
Basic Document Exchange, and Basic Informal Message Exchange. 


Degree 2: Structured Data Exchange 

This level involves the exchange of human-interpretable structured data intended for manual 
and/or automated handling, but requires manual compilation, receipt, and/or message dispatch. 
Sub-degrees are Enhanced Informal Message Exchange, Enhanced Document Exchange, Network 
Management, Map Overlays/Graphics Exchange, Directory Services, Web Access, Multi-Point 
Applications, and Data Object Exchange. 


Degree 3: Seamless Sharing of Data 

This level involves automated data sharing within systems based on a common exchange model. 
Sub-degrees are Formal Message Exchange, Common Data Exchange, System Management, 
Secure Systems Management, Security Management, and Real-time Data Exchange. 


Degree 4: Seamless Sharing of Information 

An extension of degree 3, this level establishes universal interpretation of information through 
cooperative data processing. Sub-degrees are Common Information Exchange, and Distributed 
Applications. 
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Unconnected systems, which would represent the interoperability level of degree zero, are not mentioned 
in the NATO C3 Technical Architecture. The Seamless Sharing of Information (degree 3) equals the 
Universal Interoperability Level (level 4) of Enterprise Solutions as envisioned in LISI. 


The final report of the C4ISR/Sim TRM Study Group furthermore deals the other NC3TA technical 
reference models and their applicability as well. In the context of this paper it may be worth mentioning 
that the IEEE POSIX Open System Environment (OSE) Reference Model [20] is part of these NATO 
TRM. The POSIX model is the basis for other TRM as well, e.g., the U.S. DoD and U.S. Federal 
Technical Reference Models. 


The final report of the C4ISR/Sim TRM Study Group ends with the recommendation to enhance the 
C4ISR/Sim Technical Reference Model as proposed in [16]. In addition, a C4ISR/Sim TRM Sourcebook 
and a user guide are recommended. The SISO committees accepted all three recommendations. 
Therefore, a third Study Group was launched in Fall 2002. 


5 THE C4ISR/SIM TECHNICAL REFERENCE MODEL SOURCEBOOK AND 
THE USER GUIDE TO THE C4ISR/SIM TECHNICAL REFERENCE 
MODEL 


While the previous two sections deal with conducted Study Groups, this section is dealing with the 
ongoing efforts of the third Study Group of SISO dealing with the issues of C3I to M&S interoperability. 
The results will be presented during the SIW Fall 2003. However, as the author is member of the editor 
and contributor committee for the reports of this third Study Group, preliminary results of the respective 
drafts could be comprised in this paper already. However, it is strongly recommended to look at the 
sourcebook [7] and the user guide [8] as soon as they are published. 


Two of the efforts described in the Sourcebook [7] will be described in this overview. The first is the first 
draft of the C4ISR/Sim TRM Framework; the second is the C4ISR/Sim TRM in the actual state as derived 
starting with the model as introduced by Carr and Hieb in [16]. 


It already has been pointed out that the technical solutions being already available are doomed to failure if 
not accompanied by respective organizational and procedural alignments. New evolving standards within 
the IT world — such as the Extensible Mark-up Language (XML) -- are often perceived to deliver long 
searched solutions, but in general they only affect one factor of the “house slide” as depicted in the last 
section. Without the emphasized holistic view the vision of one common command and control systems 
based on heterogeneous information technology implementing the required functionality of command and 
control as well as Operations Research — including modelling and simulation — will remain a pure wish. 
In this sense, the various TRM presented in the second report as well as in the last section of this paper are 
dealing only with special aspects of the challenge to reach interoperable and shared solutions. In general, 
all these views and models are needed to support “the big picture.” 


The C4ISR/Sim TRM Study Group first dealt with this issue in Spring 2002 and recommended as a long- 
term goal to establish a framework comprising various complementary C4ISR/SIM TRM views, following 
the example of the U.S. DoD C4ISR Architecture Framework [13] and/or the NATO C3 System 
Architecture Framework [14], both of which using operational, system, and technical views to describe the 
command and control architecture in total. Figure 4 shows the proposed structure without claiming 
completeness. The various candidates are those mentioned in the TRM sections of the previous two 
reports. 


The four recommended views are the Functions and Data View, which focuses on the data exchanged and 
functions provided via the interfaces of the M&S and C3I systems, the Software Component View, which 
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deals with the components to be addresses or reused within the participating M&S and C3] systems, the IT 
Systems View, which deals with the information technology aspects not being special to M&S or (931 
systems but still influencing their way how to interoperate, and finally the Level of Interoperability View, 
introducing the necessary measures of merits and metrics to measure interoperability as well as to define 
the level of necessary interoperability to reach a requirement driven solution. 


SISO TRM Framework 


Functions and Data View 
* Data to be exchanged 
¢ Functions to be called 


Level of Interoperability 
* NATO Interoperability Model 


‘ IT System View 


Software Component View ἢ 
* POSIX [= 


* Software Layer 
* Software Group 


ΘΑ. Tok, March 2002 


Figure 4: A Possible C4ISR/Sim TRM Framework 


All three Study Groups of SISO coping with M&S to (31 Interoperability used the model introduced by 
Carr and Hieb in [16] and improved it gradually. Although the model is mainly focussing on the 
standardization of interfaces, in particular the data to be exchanged M&S and C3I systems, and 
furthermore has been applied mainly in the domain of CAX%, it can be seen as one of the most matured 
and applied models evaluated by SISO in this context. The presented version is not the end state. It is 
much more likely that it will be further developed and improved. In particular F. Carr has to be mentioned 
in this context, who is responsible for the lion share of the improvements being done in the course of the 
three Study Groups (see also footnote on page 1-11). 


The C4ISR/Sim TRM depicts the types of data that must be exchanged between C3I and simulation 
systems in order to conduct effective events. As used here, “effective” means satisfying the user 
requirements for an event (e.g. fair fight, level playing field, real-time, data capture and replay). “Event” 


* When using M&S system to support military operations as decision support systems, a whole new set of requirements must be 
fulfilled, see, among others, Andreas Tolk and Dietmar Kunde: “Decision Support Systems in the Military Environment”, 
Chapter 6 in "/nnovations in Decision Support Systems", Tonfoni G. and Jain L. (Eds.), International Series on Advanced 
Intelligence, Advanced Knowledge International, ISBN 0-86803-980-2, Magill, Adelaide, Australia, 2003, pp. 175-210 
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means any interaction between C3I and simulation systems, irrespective of the purpose (e.g. training, 
testing, planning, analysis). The C4ISR/Sim TRM describes four broad categories of information 
exchanged between C3I and M&S systems, which are Simulation Service Interactions, Non-Persistent 
Data, Persistent Data, and C4ISR System Service Interactions. It also defines subcategories. For the exact 
definitions and examples, please refer to [7]. 
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Figure 5: The C4ISR/Sim Technical Reference Model 


Simulation Service Interactions are information exchanges that primarily support the simulation systems 
requirements. This category includes information about the simulation, and information necessary to 
control or coordinate its execution with C3I resident activities. Five subcategories are Simulation 
Metadata, Execution Control, Visualization, Data Collection, and Simulation Effects. 


Non-Persistent Data is data that will likely change during the course of an event. The interface 
mechanism selected for Non-Persistent Data must support dynamic updates. Periodic and/or event driven 
updates may be required. For example, a simulated entities’ position may be sent to a C3I system at 30 
Hertz, or only when triggered by a dead reckoning algorithm. Even though the position of an entity may 
not change during a particular event, it is still viewed as Non-Persistent Data because it is subject to 
change. Non-Persistent Data refers to the class of information that is transient, corresponding to 
interactions between entities or objects in the simulation or (31 database, or updates to an entity’s state. 
Subcategories are Orders, Reports, Imagery, Tracks, and Unit Data. 


Persistent Data is data that is reasonably static and generally set during system initialisation. The ability 
to provide direct transfer of C3I data from the suggested sources to simulation equivalents for scenario 
initialisation purposes can provide substantial cost savings, set-up time reductions, and increased 
flexibility for simulation use. So far identified subcategories are Mission & Plan Information, 
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Communication Plans, Weather Data, and Terrain Specifications. 


C4ISR System Service Interactions are exchanges of information that may be mandated by use of 
particular C3I components, or merely by virtue of being connected to a C3I system. They may not contain 
data that is exchanged between the two domains, but may be required in order to connect to the (31 
system, sustain the connection, or to use a particular C3I component. So far identified subcategories are 
System Reports on Health/Heartbeat/Status needed by the C3I system and Component Service Protocols 
required by participating C3I systems. 


The following alternative view has been developed by the author based on the C4ISR/TRM. It is 
primarily intended to extend the view from CAX to Support to Operations and to include the C3] relevant 
components on the level of the GUM. This is a high level view on M&S to C3] interoperability and is 
intended to extend the C4ISR/Sim TRM into a more general direction (by combining the Functions and 
Data View and the Software Components View as introduced in Figure 4 into one model). It must be 
pointed out that this view is actually not adopted by SISO but the personal view of the author. 
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Figure 6: High Level View on M&S to C3l Interoperability 


In addition to the sourcebook, a user guide for the C4ISR/Sim TRM, as developed by the Study Groups, 
will be published [8]. The five primary guiding principles for developing the C4ISR/Sim TRM were, that 
the TRM must be comprehensive, easy to interpret, traceable, usable, and independent. The user guide 
will in particular help to make the model easier to interpret and more usable. 
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6 SUMMARY 


The three Study Groups conducted under the aegis of the SIW C4I forum of SISO within the recent years 
help tremendously to identify burning issues within the domain of M&S to C3I Interoperability. All 
reports and interim products are available to the public via the SISO library [21]. These documents are 
valuable sources for everyone being interested in this domain of increasing importance. 


The author is convinced that C3I and M&S components will continue to merge in the future. The recent 
developments within the C3I community improved the command and control capability and quality in on 
order of magnitude by replacing the messages with a Common Operational Picture (COP), which proofs 
the saying that “a picture says more than 1,000 words.” The next order of magnitude improvement will be 
the introduction of M&S components to communicate the commanders intend in a much more efficient 
way, which could be stated as “a simulation execution says more than 1,000 pictures.” The C31 
community is still driven mainly by intelligence, surveillance, and reconnaissance resources, driven by the 
requirement to create a consistent picture out of various incomplete, unsharp, uncertain, inconsistent, and 
contradictive pieces of information. The user requirement for more agile support leads to dynamical 
structures as being supported by the M&S communities since years. Both communities, M&S and (31, 
have essential contributions to the heterogeneous information infrastructure to support the Warfighter in 
his future operations. 
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A MULTI-NATIONAL, DISTRIBUTED TESTBED FOR EXTENDED AIR 
DEFENCE BMC3I, PAST EXPERIENCES & VISION FOR THE FUTURE 


The development and testing of the BMC31I for NATO’s extended air defence mission has many challenges. 
The BMC3I element is responsible for the coordination and integration of the other three primary EAD 
functional areas: Active Defence, Passive Defence, and Conventional Counte rforce and can involve 
weapon and sensor systems widely distributed over land, sea, air, and even space. These systems may be 
operated by individual nations or integrated into NATO’s command and control structure directly. In 
addition, the missile defence aspect of extended air defence is relatively new to military operations, with 
defensive systems capable of negating ballistic missiles being deployed only within the last 10 to 15 years. 
NATO recognises the need for a more integrated approach to countering the emerging ballistic missile 
threat as is evidenced by the recently sponsored NATO Active Layered Theatre Ballistic Missile Defence 
(TBMD) Feasibility Study. 


This paper summarizes NC3A’s use of modelling and simulation in support of NATO’s EAD mission, 
specifically in the area of C2 interoperability at the technical, systems, and operational levels. It provides 
a summary of lessons learned from Cannon Cloud ’02 and other similar NATO exercises. It gives an 
overview of some on-going activities that are aimed at developing a strategy for a more cohesive, 
coordinated approach to the employment of M&S in support of EAD C2 within the NATO community, and 
some insights into what that future environment might look like. 
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1.0 INTRODUCTION 


11. NATO C3 Agency 


The NATO C3 Agency (NC3A) was established on 1 July 1996 to provide consultation and scientific 
support to NATO and is overseen by the NATO C3 Organization (NC30). Formation of the Agency was 
achieved by the amalgamation of the former SHAPE Technical Centre (STC) and the NATO 
Communications and Information Systems Agency (NACISA). The NC3A is located in two facilities: one 
in The Hague, Netherlands and one in Brussels, Belgium. The NC3A operates under the policy direction 
of the NATO C3 Board. 


The NC3A has two fundamental missions as defined in the charter of the NC3O. The first is to develop 
and implement, in a timely manner, cost-effective communications and information system capabilities to 
support NATO’s functions pertaining to both Political Consultation and Military Command and Control. 
The second mission is to provide unbiased scientific advice and assistance to NATO’s military and 
political authorities. 


1.2. Missile Defence Branch 


The work discussed in this paper was performed by the NC3A Missile Defence (MD) Branch, which 
performs a lead role in several important efforts supporting NATO’s missile defence mission area. Most 
notable are the Active Layered TBMD Feasibility Study, the Missile Defence Feasibility Study, and the 
NATO/Russia TMD Interoperability Study. In addition to these, the NC3A Scientific Programme of Work 
(SPOW), sponsored by NATOs Bi-Strategic Commanders, funds the development of the PLATO and 
LSID operational prototypes as well as the NC3A portion of the MDA/SHAPE Bi-Lateral BMC3 Study. 
PLATO (Planning Tool) is NC3A’s operational prototype for exploring missile defence planning and 
tasking requirements and functionality. LSID (Link16 SAMC2 Interoperability Demonstrator) is NC3A’s 
operational prototype for exploring the BMC3I requirements associated with realtime control and 
coordination of ballistic missile engagements. These activities are all aimed at capturing requirements for 
NATO’s missile defence mission area with the SPOW activities particularly focused on NATO’s missile 
defence BMC3I interoperability issues, and exploring synergies between functional components of MD 
(ActD, PD and CCF). 


Missile defence in NATO is a mult#dimensional operational domain. It addresses potential threat systems 
of all types, various levels of the NATO command structure, a diverse set of interface exchange 
requirements, and three main functional areas for negating the missile threat. NATO’s emerging BMC3 
systems, ACCS & the Bi SC AIS, will have to efficiently address all of these dimensions. 


To adequately capture the requirements associated with these dimensions, the Missile Defence Branch 
uses a cyclical process utilising a combination of modelling, simulation, and operational prototypes. The 
requirements are initially generated based upon the results coming out of studies and analysis activities. 
The requirements are then implemented in prototype software where they can be explored for technical 
feasibility in detail. The emerging requirements (as implemented in the prototype software) are then put in 
front of operators in realistic experiments and exercises to evaluate them with respect to their operational 
utility and usefulness. The process repeats with more and more insight and detail being developed after the 
completion of each phase. With this approach, BMC3I requirements can be generated quite rapidly even in 
a complex mission area like missile defence. They can then be included in the development programmes 
for NATO BMC3I systems (e.g., future enhancements to ACCS or the Bi-SC AIS.) 
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1.2 Interoperability at all levels 


Most NATO BMC3I systems share a common, fundamental concern: interoperability. If the BMC3I 
system does nothing else, it is usually required to make sure that its systems work together. In NATO 
missile defence, the BMC3I element is responsible for the coordination and integration of weapon and 
sensor systems developed by different nations and widely distributed over land, sea, air, and even space. 


Interoperability has to be addressed at several levels. First of all is the technical le vel: systems need to be 
connected to each other properly before they can start communicating. Then there is the system level of 
interoperability: systems need to communicate using a common protocol and message standard. And 
finally there is the operational level of interoperability: each system needs to fully understand the contents 
of the other’s messages and know how that data relates to its own information. 


One problem we tend to run into in missile defence BMC3I analyses is that we focus so intently on the 
interoperability issues associated with the reatworld BMC3I systems that we forget to properly deal with 
the interoperability issues associated with the models and simulations we use in evaluating them. We end 
up “solving” our M&S interoperability problems over and over again, for each experiment we run, and for 
each exercise we participate in. Our lessons learned are usually lessons re-learned, and the solutions tend 
to be applicable only for a given set of models and exercise objectives. 


2.0 CANNON CLOUD 2002 


We will now describe the 2002 Cannon Cloud exercise, as a case study, to illustrate how the MD branch 
supports NATO exercises and the issues that are typically encountered in such activities. 


2.1 Exercise overview 


Cannon Cloud 2002 (CC02) was the second largest exercise on the NATO calendar for that year. It was a 
large, multtcorps, mult}CAOC, computer aided exercise (CAX) conducted at USAF Europe (USAFE) 
Warrior Preparation Centre (WPC) in Einsiedlerhof, Germany, and a number of other locations. The 
primary emphasis of CC02 was to support higher echelon operational training for coalition forces in a 
large scale, high intensity conflict using the Joint Theatre Level Simulation (JTLS), an aggregate 
simulation that has served as the SHAPE-approved CAX simulation since 1995. Missile defence was only 
one part of the overall exercise objectives. 


The role of the MD Branch at the CCO02 exercise was to provide the hardware, software and 
communications capability required to provide detailed simulation of TMD activity of suitable fidelity 
such that the training objectives of the Joint TMD Cell STMDC) could be achieved. 


The exercise scenario for CC02 utilized actual Northern European terrain with fictitious national 
boundaries. The Tactical Ballistic Missile (TBM) threats were operated by the coalition of Oliveland and 
Orania against the Southern region of Montrena (figure 1). The mission of NATO missile defence in this 
exercise was to protect NATO forces in Montrena from TBM attack through Active Defence (ActD) and 
Conventional Counter Force Operations (CCFO) against the threat coalition to ensure that threat TBM 
infrastructure and support systems could be destroyed prior to TBM launch. All functional areas of TMD 
were to be fully integrated, first of all with each other, but also into the overall exercise. 
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Figure 1: Cannon Cloud 2002 country book 


2.2 NATO TMD Doctrine 


CC02 exercised all four functional areas of NATO TMD doctrine. Conventional Counterforce Operations: 
to prevent an aggressor from launching ballistic or other types of missiles by attacking identified launch 
areas and associated sites. Active Defence: to engage theatre ballistic missiles in-flight. Passive Defence: 
to mitigate the effects of an attack via camouflage, hardening, dispersal, deception, and by providing early 
warning. BMC3I: to integrate and coordinate the activities of the other three functional areas in order to 
efficiently and effectively negate the ballistic missile threat. 


During CC02, Conventional Counterforce Operations were supported by the CAESAR simulations for 
Alliance Ground Surveillance platforms, Active Defence was simulated by EADSIM, and Passive 
Defence was provided using the operational NATO Shared Early Warning (SEW) system. The JTMDC 
acted as the hub of the Battle Management/Command, Control, Communications, Computers and 
Intelligence (BMC3I) capabilities required to coordinate Conventional Counterforce Operations and 
Passive Defence. 


2.2 The aggregation problem 


One of the fundamental challenges encountered in supporting CCO2 with M&S was the issue of dissimilar 
levels of unit aggregation between models. JTLS, the core simulation for the exercise, usually aggregates 
units to the brigade level or larger. Mission specific simulations like OneSAF and EADSIM usually 
represent units at the entity level in order to accurately capture the detailed effects of signature and 
kinematics. The challenge then is to find a way for these dissimilar models to operate together. 


Figure 2 captures the nature of the multtresolution modelling problem encountered during CC02. In the 


middle is a close-up of the hexagon system used by the exercise planners to represent the battle space. 
Each hex is 7 kilometres across. 
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Figure 2: Cannon Cloud 2002 aggregation problem 


On the right is a representation of an entity-level simulation used by the CAESAR sensor simulations for 
Conventional Counterforce Operations. Individual buildings, trees, 100-meter resolution terrain data and 
roads are all represented in the AGS simulation world. 


The errors that arise when combining such simulations can be generalised as: 


e Time synchronisation, especially when considering moving targets, 
¢ Location errors are clear when you consider that JTLS generalises features across 7km, 
¢ Velocity, road registration and features are also of concern. 


The challenge was to develop an architecture to address these issues. 


Figure 3 shows the architecture that was designed to support the TMD operations and to address the issues 
mentioned above. The architecture minimises the effects of concurrently running dissimilar simulations. 


JTLS, again, is the primary simulation. TBM units operated on pre-planned schedules represented by 
scripts in ITEST and in JTLS. JTLS issues the TBM fire command to EADSIM, which then flies the 
ballistic missile and conducts the intercept using Dutch and German Patriot units and the Dutch Navy 
Frigate. When the EADSIM launch occurs, the HLA listener relays the launch information to the SEW 
Alerter, which injects the launch warning information into the NATO WAN. On the AGS side, the sensors 
detect the moving entities of ITEST and feed exploitation systems using the common data format (NATO 
EX). This allows the sharing of national sensor system data. 
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Figure 3: Cannon Cloud 2002 TMD simulation architecture 


This architecture solution worked and TMD objectives of the exercise were achieved. However, the use of 
multiple, simultaneously running scripts (one for JTLS and one for ITEST) was prone to synchronisation 
problems, had the potential for data mismatch, and did not allow the exercise planners much flexibility to 
dynamically change the course of events. In short, the solution worked, but required quite a bit of effort to 
set up and to keep events and data synchronised. 


Another issue that arose during CCO2 was an appreciation for the huge number of entities required to 
accurately reflect background traffic for the AGS simulations. If not managed properly, these entities 
would quickly swamp computer and network resources. 


The typical modelto-model interoperability issues were also encountered. Although HLA was used as the 
interface between JTLS and EADSIM, both simulations lacked FOM agility. This resulted in a FOM that 
was driven more by what the models could be made to easily produce than by the CC02 exercise 
requirements. The developers of both tools were needed to achieve a functioning federation, and 
specialised software versions were created. While the TMD objectives for the exercise were met, it 
required a large investment in time and manpower to achieve. These issues are by no means peculiar to 
these models or this exercise. In our opinion, they represent a common set of challenges that are faced in 
most distributed experiments and exercises. 


3.0 VISION FOR THE FUTURE 


CC02 is only one example of the many types of activities the MD Branch is requested to support with 
M&s and prototyping. It is a useful example in that it brings attention to the various problems and 
challenges associated with M&S support for large scale, distributed exercises. However, as mentioned 
previously, it is also illustrative of the constraints that any future M&S activity is likely to encounter. 
Some of these constraints include: 
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e Exercise/experiment specific goals, objectives, and requirements. 
e Limited NC3A manpower and specialised expertise. 
e Amixture of DIS and HLA compatible models and prototypes. 


¢ For HLA compatible models and simulations, the SOMs will almost certainly not map directly to 
each other. 


e Lack of access to source code and/or simulation developers. 
¢ Potentially large number of entities (especially for AGS applications). 
e Never enough time. 


These must all be taken into account as we formulate our vision for a missile defence interoperability 
testbed at NC3A. 


31 The NC3A Missile Defence Interoperability Testbed 


The overall objective of the NC3A Missile Defence Interoperability Testbed is to create an environment 
for addressing missile defence interoperability issues in the near-term. We want to create an environment 
where the M&S interoperability issues are addressed up front and independent of any particular exercise 
or experiment. We want these issues resolved in a way that allows our analysts to focus on the branch’s 
primary functions of:: 


¢ Verification and validation of NATO’s command and control concepts of operations for missile 
defence. 


¢ Identification and evaluation of missile defence C2 system requirements. 
e Test and evaluation of missile defence prototype software. 
e User-in-the-loop concept evaluation. 


The testbed should provide an environment that allows us to perform these functions without creating an 
unduly large burden on the branch. In other words, the testbed should support the existing objectives of 
the Missile Defence Branch and NC3A, and not become an objective in and of itself. 


This environment will also need to support all three of the major types of activities that the branch 
performs. These activities as described previously include, Studies and Analyses, Prototype Development, 
and Exercise/Experimentation. The testbed must support all three types of activities and provide as much 
commonality as possible to ensure the smooth transition from one activity type to another, while 
minimising training and manpower costs. 


NATO is currently tasked with providing an effective missile defence of its deployed forces. It must 
perform this mission using an assortment of weapon and sensor systems provided by the NATO member 
nations. With this in mind, it is easy to see why operational, system, and technical interoperability are 
among NATO’s highest priority challenges. The focus of the Missile Defence Branch, and therefore this 
testbed, is on missile defence interoperability issues associated with realtime and non-real-time C2 
functions. The testbed must address and facilitate the identification of data exchange requirements, the 
exploration of potential synergy between the functional areas of missile defence, and the raising of reat 
world, missile defence BMC3 issues before weapon, sensor, and C2 systems are fielded in an operational 
setting. 


The testbed vision described in this document addresses a specific, near-term missile defence need within 


NATO. One of the conclusions coming out of NATO’s Active Layered Theatre Ballistic Missile Defence 
Feasibility Study (ALTBMD FS) is the need for a testbed to reduce the schedule risks associated with the 
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integration of a variety of weapon, sensors, and BMC3 systems. By establishing a distributed testbed 
capability, integration and interoperability issues can be identified and resolved well in advance of system 
fielding. As part of the Capability Package resulting from the ALTBMD FS, an Integration, Test, and 
Evaluation Testbed is being proposed with an estimated 2006 IOC date. 


The problem with this is that NATO’s primary C2 systems that will be used to plan, task, and execute the 
missile defence mission (ACCS and Bi-SC AIS) are in development now with the initial missile defence 
requirements being analysed and developed over the next couple of years. Also, within the operational 
community, the missile defence CONOPS are currently being refined and evaluated to deal with ballistic 
missiles of extended ranges and WMD capabilities. The testbed vision described in this paper addresses 
these near-term needs in support of NATO C2 system requirements capture and military CONOPS 
development, and is envisioned as a bridge to the future integration testbed defined in the ALTBMD FS 
Capability Package. 


Our vision of a useful testbed is more than just a collection of models that can exchange information with 
one another. It includes the following dimensions: 

¢ Facility related infrastructure. 

e Hardware related items. 

¢ Core simulations and models. 

¢ Prototype software. 

¢ Distributed simulation capability and support infrastructure. 

e Analysis tools. 

e Support staff and training. 

¢ NATO reference databases. 


Each of these areas will be addressed in more detail in the following sections. 


3.1.1 Facility related infrastructure 


The facility supporting the testbed should be able to handle NATO security levels up to and including 
NATO Secret. It must allow repeated access to military and technical representatives from NATO member 
countries and their equipment, and have the necessary NATO network connections to allow remote 
participation in NATO experiments and exercises. 


3.1.2 Hardware related items 


The missile defence interoperability testbed should have a robust hardware suite available to it. This 
hardware suite must support prototype and model hosting, a centralised server capability, sufficient 
storage and network capacity, communications interfaces to distributed locations, as well as a well- 
documented and tested backup system. The objective here is to have the required hardware capability and 
system administration processes developed and in place before (and independent of) any specific exercise. 
This will provide a stable, familiar, and well-documented computing environment for conducting missile 
defence experiments and exercises. It will also reduce the need and associated risk of trying to acquire 
computing and network hardware to support a specific event. 


3.1.3 Core simulations and models 


The interoperability testbed can be thought of containing two broad categories of simulations. The first 
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category can be described as “core” tools that model theatre level interactions and effects. Because of the 
limited amount of available manpower, this set has to be reduced to a relatively small suite of models that 
must cover a range of capabilities and functions. These models must support studies and analysis, 

prototype development, and exercise/experimentation objectives. In addition, they must be able to 
exchange information with each other either by common data structures in support of analysis efforts or by 
distributed simulation techniques such as HLA (High Level Architecture) or DIS (Distributed Interactive 
System) in support of experimentation. 
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The second category can be described as weapon, sensor, and C2 system emulators. These will vary from 
experiment to experiment and will often be supplied and supported by technical experts from NATO 
member nations. This set also includes actual weapon and sensor system hardware. This category of 
simulator/emulator is distinguished from the previous set of models and simulations in the following 
ways: 


e The emulator functionality is narrowly focused on the functions of the system it is representing. 
¢ NC3A will almost certainly not possess expertise in using the emulator. 


e Like the theatre level simulations access to source code is usually not available, but access to 
technical experts with the ability to make code changes on the fly is not unheard of. 


In general, these emulators will be available for a short time to support the specific exercise or experiment, 
and will then be removed. 


3.1.4 Prototype software 


One of the fundamental objectives of this interoperability testbed is to provide an environment for 
stimulating and testing NC3A’s missile defence prototype software. The prototypes follow a spiral 
development process that requires continual interaction with the military operations community with 
stimulation from realistic representations of the weapon and sensor systems they will be controlling. The 
following attributes describe how the NC3A prototype software differs from the models and simulations 
described in the preceding section: 


e Access to source code (primarily written in Java) 
¢ Continually changing software in response to emerging operator requirements 
e Prototype developers are not necessarily HLA or DIS experts 


By facilitating the running of experiments using NC3A’s missile defence prototype capabilities, more 
frequent iterations can be made in the spiral development process, and requirements capture can be 
achieved more rapidly. 


3.1.5 Distributed simulation capability and support infrastructure 


A distributed simulation capability is a prerequisite for the interoperability testbed. The testbed must allow 
for the inclusion of legacy systems still using DIS, but should be based upon HLA and take advantage of 
the benefits it provides. A FOM that is specific to the needs of the missile defence mission area should be 
defined, and the core models should be made to conform to it. A customised FEDEP (Federation 

Development and Execution Process) should be developed for the interoperability testbed taking into 

account its core capabilities and reoccurring elements and processes. 


One particularly important aspect of this distributed simulation capability is the way in which tactical data 


links (TDLs) are represented and accessed. TDLs are the basic information exchange methods by which 
NATO’s operational and technical elements communicate with each other. They are standardised and 
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baselined in NATO Standardization Agreements (STANAGs) signed by the NATO member nations. The 
interoperability testbed must reflect these communication standards to ensure that modelled systems are 
constrained in the same way that reatworld systems are. 


Finally, in-house HLA expertise and a set of network/HLA diagnostic tools are necessary, as debugging 
and analysing distributed experiments can be extremely difficult and time consuming. 


3.1.6 Analysis tools 


A common set of tools designed for distributed experiment analysis is necessary to efficiently collect, 
reduce, and display the results of an experiment. This is particularly important for experiments and 
exercises where a large number of people are involved. As distributed experiments tend to generate large 
volumes of data spread across multiple computers, this can also be a very challenging task. The chief 
objective here is to allow people to spend their time addressing, analysing, and discussing the experiment 
results, not waiting for the results to be collected and displayed. The ability to quickly and succinctly 
generate “After Action Reports” would ako be extremely useful. 


3.1.7 Support staff and training 


To run this testbed effectively, a team of trained and experienced staff are necessary. As staffing levels are 
always lower than desired, the testbed support staff needs to consist of flexible individuals with expertise 
in multiple areas including: technical management, core simulation expertise, HLA/DIS federation 
construction and execution issues, as well as computer hardware, software development, and network 
experience. These individuals must also be able to effectively communicate with technical staff supporting 
other event specific applications as well as personnel from the military operational community 


3.1.8 NATO reference database 


The final dimension that makes up our vision of a missile defence interoperability testbed is access to a 
well-defined and sanctioned set of NATO reference databases. These databases include environment 
models (e.g., terrain, standard atmosphere, earth spheroid, etc) as well as threat representations, 
weapon/sensor system models, and standard scenarios blessed by the NATO military staff. In addition, 
these databases should include reference architectures, command structures, and BMC3I models for 
NATO ACCS and B:tSC AIS entities. These databases must be accessible, controlled, and maintained. 
The objective is to have the desired data, ready to go, with no development or set-up time required. 


3.1.9 Potential software and network components 


Having addressed some of the general features of our testbed vision, it § now useful to look at some 
potential software and network components to start to get more specific and identify a roadmap for 
achieving our vision. Figure 4 above shows the different categories of models, simulations, and software 
tools and reinforces some of the points made in the previous discussions. The important thing to note is 
that any particular exercise or experiment will contain only a subset of the elements listed. The key then is 
to identify a set of core models and a flexible infrastructure that will facilitate the inclusion of a variety 
system emulators and prototypes. 
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Figure 4: Different categories of models, simulations, and software tools for the testbed. 


As we move to a more specific vision of the future, it is also useful to think about how the NC3A Missile 
Defence Interoperability Testbed will relate to the ACCS System Test and Validation Facility (STVF) as 
well as national test facilities. Our vision is that the NC3A Missile Defence Interoperability Testbed will 
provide a fundamental part of the Integrated Test and Evaluation Testbed when it comes on-line in the 
2006 time frame. Connecting operational prototypes at NC3A with the ACCS system software at the 
STVF and weapon and sensor simulations at national facilities will allow NATO to explore new C2 
CONOPS as well as validate technical information exchange requirements and implementations. 


3.2 NC3A HLA Initiative - Objectives ἃ Goals 


So far we have discussed our overall testbed philosophy and vision. We have also provided a brief 
description of what we think our testbed will look like in the future and how it will relate to other missile 
defence testbed facilities that exist or are planned. However, before concluding, we would like to discuss 
two current, on-going activities that are aimed at taking concrete steps towards achieving our vision of a 
missile defence interoperability testbed. 


The first activity is the HLA Testbed Initiative that is being conducted by the Missile Defence Branch and 
TNO. The project’s primary objective is a report summarizing a set of recommendations for the 
development of an HLA federation to support NC3A’s Missile Defence Interoperability Testbed. This 
report is to be accompanied by a proof-of-principle experiment demonstrating the viability of the report’s 
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recommendations. Specific areas addressed by effort are: FOM agility options for simulations developed 
by 3" parties, RTI selection, and ways to facilitate HLA-enabling of the branch’s JAVA-based prototypes. 
The proof-of-principle demonstration will include EADSIM, EADTB, LSID, and the SEW display 
software. EADSIM and EADTB represent the category of large, theatre-level simulations that are 
deployed without source-code and have differing HLA implementation approaches. The LSID and SEW 
software represent the class of federates that are developed by NC3A. These NC3A developed prototypes 
can be modified, and their inclusion is meant to test the ease with which they can be integrated into an 
HLA federation. This initiative is close to completion, and will form the basis for the Missile Defence 
Branch’s HLA implementation approach for the Interoperability Testbed. 


3.3. MSG-006/TG-006 Participation 


The second major activity supporting NC3A’s missile defence interoperability testbed implementation is 
our participation in the NMSG’s MSG-006 Task Group. This task group was established to investigate 
“M&S Support to Assessment of Extended Air Defence C2 Interoperability” in a NATO environment. The 
task group’s objectives include evaluation of the feasibility of reusing existing simulation components and 
testbeds across NATO in an integrated, distributed fashion. In addition, and perhaps more importantly, the 
task group will recommend approaches to distributed simulation architectures that will enable extended air 
defence C2 interoperability analysis. This will include the development of a recommended reference FOM 
and a FEDEP tailored for extended air defence. While the HLA testbed initiative project addresses issues 
such as how to get federates to use a common FOM, one of the important products of the MSG-006 task 
group will be a recommendation on what objects and interactions should be included in that FOM. This is 
critical if the missile defence analysis community is going to take full advantage of the benefits that HLA 
can provide. 


4.0 SUMMARY 


In summary, NC3A depends heavily upon the use of modelling and simulation to support missile defence 
C2 interoperability analyses for NATO. Experiences at Cannon Cloud ’02 and other similar NATO 
exercises demonstrate the need for a missile defence testbed that allows analysts to focus on the C2 
interoperability issues rather than the M&S interoperability issues. For this to occur, a set of objectives 
and requirements for a testbed environment is needed and must be followed by a concerted, focused 
implementation effort. The Missile Defence Branch has identified what such an environment would look 
like and is involved in specific activities that are aimed at achieving it. 
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Abstract 


In this paper, TUBITAK’s (Technical and Scientific Council of Turkey) experience in C4ISR 


domain and a simulation tool being developed are summarized. 


1. Introduction 


Nowadays, C4ISR as an integrated military structure attracts more emphasize in parallel to 
developments on information technologies and knowledge engineering. C4ISR systems merge 
both physical components and information-oriented aspects like decision-making and 
message exchange between participating components. Combining both world layers, physical 
and information, provides wider worldviews allowing modelers and analysts to design 
inclusive and comprehensive defense simulation tools addressing war games, C2 analysis, 
concept development and gaining management experiences on them. In simulation literature, 
information and physical items flows are known as opposite to each other. Bringing both 
flows together and satisfying analysis requirements of being together is not an easy task 
making more elegant modeling approach especially for reusability, modularity and 
interoperability, mandatory. As an integrated and complicated domain, the problem of C4ISR 
concepts development as well as staff training generally requires experimenting on complex 
scenarios. Simulating these scenarios in virtual environments and coupling them to real 
C4ISR systems and staff is significantly cost-effective solution for the problem [1]. 


From the simulation point of view, modeling information layer is pretty different from 
modeling physical layer. Variety of information types, concurrency, probabilistic nature of 
information and its flow among operational nodes, in addition to all, infeasibility of fully 
automated decision making as well as data fusion make modeling a very complicated task. So, 
that requires knowledge intensive and highly autonomous components in addition to well- 
formulated mathematical models solvable by operational research methods. This reveals man- 
in-the-loop simulation as a practical solution for the problem. That is one of the essential 
factors for planning C4ISR simulation tools interacting with human in run time. 
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TUBITAK is developing an open, reusable, modular and interoperable simulation system for 
modeling and executing C4ISR architectures. This paper summarizes the lessons-learned up- 
to now and relevant projections for future. The simulation system has an open architecture on 
two points. The first point is generating a distributed infratructure consisting of reusable 
components. This is achieved by setting up the whole system on HLA/RTI middleware; it is 
possible to insert external simulation or software components, even in run-time to a scenario 
which is being executed as a federation as well as deploying the components in other HLA 
federations. The other point emphasizes openness to new developments by having modular 
and well-interfaced component architectures. 


The system could serve for concept development, analysis and training purposes. Military 
Concept development is achieved by being able to try different scenarios. They consists 
architectures of C4I and SR components allowing declaration of operational information flow 
among each other. Results of scenario execution are elaborated using the analysis functions of 
the system. Analysis outcomes are revised to restructure the scenario for better architectural 
concepts. The analysis has done in two ways; in the classical way, as is the simulation post- 
data analysis, and the second way, optimization for component behaviors with respect flexibly 
defined criteria. Moreover, trainees are faced with different cases in scenarios to examine and 
feedback their strong and weak sides in developing C2 decision and actions. 


The following sections present rationale and features of the system. 
2 Rationale For C4ISR Simulations 


Essential idea behind the C4ISR concept is developing system of entities and their 
interoperability definitions rather than entities themselves. Hence, the main motivation for 
C4ISR simulation systems is being able to model many individual and interoperable 
components into one common integrated virtual environment. Stressing integrated view 
follows up the need for modeling an environment promoting analysis of architectural concepts 
as well as decision making of corresponding staff. It could be modeled at different layers of 
C2 process, that are; modeling multi-sensor and multi-source data fusion, modeling decision 
support mechanisms, modeling whole C2 staff decision making process as well as modeling 
behavioral and decision making capabilities of enemy forces. For such analysis, features 
concerning information and its flow within organizations should be involved within 
simulation models. By incorporating information, users and analysts could reason about 
operational success of components, their level of integration as well as amount and quality of 
data they produce. This includes examining connectivity effectiveness and performance issues 
about information amount and flows. 


Training staff and testing new components in typical and extreme situations within such a 
broad sense (integrated systems) is costly and in some cases not very practical. As C4ISR 
scenarios could be developed and executed in virtual environments, training and trials of real 
elements becomes matter of interfacing the systems to the virtual environments. This provides 
very efficient way for performance examination of system components in various condition 
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and cases. System acquisition policies could well be established on such tests done using 
virtual environments. 


Strategical and tactical rehearsal of C4ISR systems needs many elements to be fed by exercise 
context of scenarios belonging to various operational cases. Developing realistic operational 
cases in peacetime is partly possible. In spite of the fact, nowadays many real-world items 
could be well-featured using virtual mediums. Consequently, C4ISR modeling and simulation 
environments offer such realistic resemblence to its real world operational en environmental 
conditions counterparts. This is used in strategical and tactical rehearsals involving virtual 
C4ISR context. Strategic and tactical confinement as well as force organizations subject to 
geo-politic and doctrinal considerations that vary for each country. Virtual simulation 
environments could be tailored to reflect such doctrinal chracteristics. 


3 Purposes Of the C4ISR Simulation Environment 


A C4ISR modeling and simulation environment development project is currently being 
carried on by TUBITAK. It involves modeling, simulation and analysis capabilities for 
various C4ISR architectures emphasizng ISR missions. It will consist of various types of 
component models running as HLA federates on RTI. Component models will be modular 
and well interfaced letting cast of different scenarios. The system will allow deployment of 
C2, Communication, Computer, and ISR component models and definitions appropriate for 
both physical and information layer. Main features of the system are as in the following. 


User could define an integrated operational scheme by having tools to lay down components 
on the scenario region and specifying their technical and operational capabilities. This will 
provide the physical layer construction of the scenario. These component models are defined 
as types of sensors, communication systems, C2 systems and weapon systems. Another 
definition will involve architectural and operational integration of components under a 
common command and control structure. There will be definitions on organizational features 
pertaining to operational, system and technical views of the architecture. This will give 
information layer designations. 


The system will have tools allowing static and dynamic optimization of sensor deployment, 
their coverage optimization and multi-sensor route planning. User could define cost functions 
and constraints of performance measures. These mesaures could be defined with respect to the 
missions of scenario. 


Sensor detection, classification and identification data will be integrated using fusion models. 
There will be two types of data Fusion; sensory and information (commented data) data 
fusion. This capability will support examining how the fusion concept affect decision makers 
job. Also testing various fusion approach and techniques would be possible. If required 
tactical picture based on fused data will be avalibale to C2 staff. 


Analysing different C4ISR architectures under various conditions will add measuring 
effectiveness of architectures in real-time performance, tactical criteria and information 
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format and sufficiency etc. This will enhance peacetime review of organizational 
effectiveness for contingency conditions. 


4 Branches of the simulation environment 


The simulation environment consists of “Scenario design’, “Scenario engine’, “Analysis”, 
“Optimization”, “Autonomous forces”, ” Communication”, “Sensors”, “fusion” and “map 
functions” main components. 


Scenario design tool allows modelers to define scenarios. Scenario definition phase starts with 
choosing a map in DTED format. Simulation component toolboxes let scenario designer to 
choice any components and place on the map. The components in the toolboxes are stable and 
moveable platforms, communication devices, command and control units, personnel 
(including enemy), fire support units, sensor systems and man-made structures such as 
milestones, buildings, borderlines, watchman tower and mine fields. All components are in 
generic form and have their own attributes that can be edited by the scenario designer to 
translate them into more specific ones. Moreover, getting the components in the scenario 
more specific, it is possible to equip a component with some other components such as 
assigning a pistol to a private, to prepare some ready to use scenario components such as route 
definition, area definition and assign them to related components as subcomponents. Possibly, 
the most critical definition in scenario design is mission declarations consisting of what 
component has what goal and how they succeed them. “What” part is modeled in mission- 
task-activity tree structure. Each mission and its tasks have their own “success constraints” 
and each method of the tasks have their applicability constraints and a process, namely “How” 
part, declaring in what structure the methods are applied. The scenario engine accepts the 
whole declaration to implement. 


Scenario engine is a manager agent expanding component mission definition by watching the 
simulation environment. It basically checks the task applicability conditions and applies 
implementation process sending messages related simulation component declaring “what to 
do” and gets a succeed result back. 


To be able to build the scenario in C4ISR structure, architectural definition components are 
provided to ensure C4ISR completeness of scenarios. Architectural components are 
summarized under three main headlines. They are Operational view, System view and 
technical view. In operational view, the environment provides high-level operational concept 
graphic, in which operational nodes are defined and declared what the simulation components 
belong to, organizational relationship chart, operational node connectivity description, 
operational node connectivity diagrams. C2 hierarchies and Commander responsibility area 
and types are defined by organizational relationship chart. 


System view is related with assigning the system to the tasks to do and the communication 
devices to the messages defined between operational nodes by operational node connectivity 
diagrams. Technical view provides a series of interfaces providing opportunities creating 
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queries for both applicability checking of activities implemented by a component and 
suitability checking of a device for a specific task or choosing the better device for it. 


Analysis module undertakes two central tasks. The first one is to create simulation input data 
such as random number values form theoretical distributions, random number streams. The 
second task is to make queries on execution results and subject to statistical analysis such 2, 
ANOVA. This task is also used for performance analysis. 


Cost-effective optimum sensor deployment and sensory platform path planning are main task 
of optimization tool. Optimization finds optimum sensor combination allowing maximum 
coverage or optimum sensor combination under some budget constraints. Depending on 
sensor types, sensor models pick information from environment especially enemy sources and 
send command layers them via communication devices and command layer make decision 
fusing the information coming from multiple sources by data fusion algorithms. 


Map functions are fundamental for visibility and coverage area computations for both sensors 
and communication devices. All models in the system are modeled effect modeling approach 
rather than physical modeling. 


5 HLA Compatibility 


Each scenario will be a different HLA federation running on RTI middleware. To support this 
structure, sensor, communication, platform, staff and C2 components are represented as 
federates. Components could dynamically publish or subscribe object/attribute/interactions 
during execution. 


The system could run in real-time and logical time modes. A separate coordinator federate 
will manage time and phase synchronization. Also preprocess, execution, post-process and 
replay functions will be managed by coordinator federate. 


Federates are structured in a layered form. Model calculations and federate interface will be 
separate modules each interacting through interface functions. This will enhance replacing the 
calculation side with others having different approach and implementation. 


On the other hand federated component models could be deployed into separate processors. 
Higher performance would be achievable when the system is loaded with a complex scenario. 
Also training features will be promoted by breaking up each federate onto separate computer. 
Federate user interfaces support this capability. Consequently each C2 federate user/operator 
could see the tactical picture of its own knowledge base. 


6 Usage Concepts 
The simulation tool is planned to be used aspecially in four main domains. These are 
1) Training, 
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2) Rehearsal, 
3) Analysis and 
4) Optimization 


In training purpose, users are expected to get insight some fundamental sensor usage 
concepts. Rehearsal is thought mostly to improve talents of tactical analysis and tactical 
planning capabilities of users. 


The main stress on Analysis module is performance analysis. The aim is to put differences 
between users forward and to watch their improvements. 


Optimization is for planning purposes. The planning consists of deployment of sensors on an 
area, combination of sensor type and numbers, and movable sensors’ path planning so that 
maximum coverage is satisfied under cost constraints. 


7 Results 


The main characteristic of the study is the effort to bring together information layer 
simulation together with the layer in which models of real world physical entities are 
simulated. This effort matches what C4ISR aims to do. 


The simulation tool has the properties enumerated below; 
e Hybrid simulation models: discrete and continuous together 
e Effective modeling rather than physical modeling 
e HLA-based distributed simulation 
e Includes an optimization module 
e Serves a base for data fusion 


e Analysis for both tactical and training 


2T RTO-MP-MSG-022: C3/ ἃ Modelling and Simulation Interoperability 3-6 


LAMIZAT 


8 References 


[1] Roberts J.D., Dobbs V.S., “Simulation to C4I Interoperability for Planning and Decision 
Support’, Fall Simulation Interoperability Workshop, SISO, 2001,Orlando, FL 


[2] Griffith J., Sielski K., Frye H., “C4ISR Handbook’, the Integrated C4I Architecture 
Division, Architectures Directorate, Office of the Assisstant Secretary of Defense, 
1998,Washington D.C. 


[3] “C4ISR Architecture Framework Version 2.0”, C4ISR Architecture Working Group, 
December 1997 


2 RTO-MP-MSG-022: C3/ ἃ Modelling and Simulation Interoperability 3-7 


Ι 
«Φ 
YW 


Training & Education Enhancement Programme (TEEP): 
Current Status and Way Ahead of Advanced Distributed 
Learning (ADL) & Simulation Portion 


LtCol Jean d’Andurain 
NATO HQs, International Military Staff 
Co-operation & Regional Security Division 
39 Blv. Leopold III 
Brussels 1110 
crs.ps@hq.nato.int 


OVERVIEW 


Endorsed at the Washington Summit, confirmed at the Prague Summit, the Training and 
Education Enhancement Programme is viewed as a useful tool to achieve interoperability 
and considerable progress has been made in several areas in the past year, especially in 
its Advanced Distributed Learning and Simulation component. A number of studies have 
been completed with the expertise of the RTA/NMSG, the NATO Training Group (NTG) 
and others in support of NATO Strategic Commands, with Allied Command Transformation 
(ACT) in the lead. 


The ADL prototype is considered a success and the establishment of a NATO/PfP ADL 
capability supporting NATO/PfP Education and Training is feasible. ACT has been 
requested to propose a course of action to implement it, including the continuation of the 
prototype use with National contributions until a Capability Package (CP) is developed. 

It is feasible and cost-effective to use distributed simulation for training. ACT has been 
requested to propose a course of action to implement it through the execution of a set of 
distributed NATO/PfP prototype exercises, and the development of a CP including a 
successor of Allied Command Europe (ACE) Command and Staff Training Programme 
(ACSTP). 


BACKGROUND 


The December 1998 North Atlantic Treaty Organisation (NATO) Ministerial meetings 
tasked the North Atlantic Council (NAC) to identify and consolidate initiatives underway in 
Partnership for Peace (PfP) in order to form a coherent package of measures to reinforce 
PfP’s operational capabilities. Education and training activities such as the PfP Training 
Centres, the PfP Simulation Network and the PfP Consortium of Defence Academies and 
Security Studies Institutes were identified as appropriate subjects for consolidation. 
During the April 1999 NATO Summit in Washington, Heads of State and Government 
endorsed the resulting PfP Training and Education Enhancement Programme (TEEP). 


The TEEP is to provide a structured approach to optimise and improve training and 
education in the Partnership to meet the current and future demands of an Enhanced and 
More Operational Partnership (EMOP), focussing specifically on the achievement of 
interoperability. 


Paper presented at the MSG-022/SY-003 Conference on “C3I and M&S Interoperability”, 
held in Antalya, Turkey, 9-10 October 2003, and published in RTO-MP-MSG-022. 


This paper reflects the author's personal views on the subject 
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The TEEP programme was re-endorsed during the November 2002 NATO Summit in 
Prague, where the Alliance took the decision to upgrade NATO co-operation with the 
EAPC/PfP countries and highlighted the requirement to continue to further enhance 
NATO/ PfP interoperability as part of the transformation agenda. Critical to this approach 
is the need to support the development of Combined Joint Task Force (CJTF) 
headquarters and to expand the strategic reach of the co-operative building effort to 
include Central Asia and the Caucasus. 


The TEEP programme encompasses six components: 
- linkages and collaboration; 

- feedback and assessment mechanism; 

- interoperablity; 

- exercises; 

- national training and education strategies; 

- advanced distributed learning & simulation (ADL). 
This document will focus on the latter component only. 


THE VISION 


To implement Prague Summit mandates in strengthening NATO-PfP education and 
training collaboration as part of the transformation agenda, it is essential to build upon 
existing efforts, and only where necessary to explore the need to establish new information 
technology capabilities. The desired long-term end state vision is to provide Allies and 
Partners with a multinational training and exercise environment up to the CUTF “command 
and staff’ level, supported by a near-real-time interactive ADL and Simulation environment 
that: 

- Supports combined, joint operations; 

- Links military, political-military, and civil-military components into simulation, modelling 
and training; 

- and, Integrates such distributed training with focused professional military education 
delivered through ADL. 


It is worth noting that the strengthening of NATO-PfP education and training not only 
benefits Partners, but also NATO Nations and the Alliance as a whole. 


The studies highlight that there is not yet a single, coherent strategy nor an implementation 
plan that links and co-ordinates existing key agencies within NATO and PfP to achieve 
enhanced interoperability and which satisfies NATO and Partner requirements for training 
and education in NATO-led, Non-Article 5, combined, joint operations down to the battalion 
level. The key agencies, infrastructure and processes that should be linked and co- 
ordinated to reach those objectives are illustrated as shown at the figure below: 


This paper reflects the author’s personal views on the subject 
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Supreme Allied Commander Europe, recently renamed ACT Allied Command Transformation; NS(S) NATO 


School (SHAPE) recently renamed NATO SHAPE (Oberammergau); NTG NATO Training Group;PCC 
Partnership Co-ordination Cell 


The Washington Summit TEEP-related initiatives of PfP Training Centres, PfP Simulation 
Network and PfP Consortium of Defence Academies and Security Studies Institutes 
continue to form an interlocking and coherent package of measures to reinforce PfP’s 
operational capabilities. To implement Prague’s direction to intensify this effort in support 
of Transformation, explicit NATO counterpart efforts need to be identified and reinforced. 
Among the benefits that the nations may expect to receive in return from this collaboration 
with NATO is higher levels of interoperability, including the capability to co-evolve 
organisation, command concepts and doctrine among the many nations that will be 
sharing advances in technology. 


The figure below summarises the necessity to align on-going PfP TEEP activities referred 
to above with their corresponding NATO counterpart: a NATO Distributed Simulation 
initiative, NATO School (Oberammergau) (NS(O)), and the NATO Defence College (NDC). 
In addition the figure highlights the needs to create a permanent nucleus at ACT to co- 
ordinate NATO-PfP ADL & Simulation efforts. These ideas comprise the central elements 
of the NATO-PfP training transformation effort that can be supported by Advanced 
Distributed Learning and Distributed Simulation capabilities. Implementation of this vision 
is enabled and supported by the links established with the TEEP- related Training and 
Education Initiatives, which have been instrumental in bringing diverse training and 
education communities into a mutual support framework. 
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Mutual Support Activities 


NATO/PfP 
Training Centers 


NATO/PfP 
SIMNET NATO 
Distributed 


ACT SIM Simulation School 
Office (Ogau) 


NATO/PfP Education 
Institutions 
PfP Consortium 


A MULTINATIONAL ENVIRONMENT 


Since their establishment at the April 1999 Washington NATO-EAPC Summit as “new 
tools” in support of NATO-PfP interoperability, the PfP Consortium of Defence Academies 
and Security Studies Institutes, the PfP Simulation Network, and PfP Training Centres 
have flourished. 


As “in the spirit” of PfP activities, they have benefited from the convergence of national and 
multinational support, while remaining free from subordination to any particular national 
agenda or direct NATO involvement. Driven largely by the principle of voluntarism, they 
provide a unique, mutually supporting venue for concept development and 
experimentation. Exploring new approaches to security cooperation and interoperability, 
they analyse lessons learned and help to share best practices. 


Consequently, these three major “tools” of TEEP provide a foundation for NATO- 
PfPtraining transformation, consistent with PfP’s principle of “self-differentiation,” whereby 
nations determine for themselves what they wish to contribute or to receive. Collectively 
they assist in the development of a cooperative network of security institutions. 


PfP Consortium of Defence Academies and Security Studies Institutes 

The PfP Consortium constructs new tools to support collaborative learning between 
nations and is at the origin of NATO’s own capabilities in critical transformation areas. It 
provides a unique example of international cooperation in the multinational development of 
e-learning applications for security cooperation. The end state vision of a virtual 
multinational learning environment that links military, political-military, and civil-military 
components into distributed modelling and simulation environment supported by focused 
professional military education is a realistic goal attainable in collaboration with the 
Consortium’s core ADL development capability. 

Switzerland’s support through the PfP Consortium has been a critically important element. 
Swiss teaming arrangements with Allies employing the ADL Co-lab SCORM standard was 
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the principal factor in the development of technical tools and learning material for 
NATO/PfP ADL. Switzerland further provided the leading support in coordinating and 
integrating Voluntary Contributions by joining a wide array of PfP Consortium experts from 
throughout the EAPC region through the PfP Consortium’s ADL, Simulation and Curricula 
Working Groups. As NATO implements the Prague Summit mandate for EAPC-PfP 
activities, an essential element in the success of the NATO-PfP transformation effort will 
be to ensure the preservation of distinctive Partner nation lead roles and responsibilities 
and align them in a corresponding relationship with the NATO Defence College. 


PfP Training Centres 

Nine Allied and Partner Nations participate in providing PfP Training Centres, most of 
whom focus on operational and tactical level training and instruction in NATO/PfP staff 
procedures and other individual skills. NATO has a link to them through the NATO School 
(Oberammergau), and they agreed in their last Conference of Commandants to increase 
their role in ADL and Simulation development in support of enhanced NATO/PfP 
Interoperability.. Increased attention to advanced distributed learning and distributed 
simulation shared among and between the Centres could lead to new synergies, leverage 
and multiply the use of scarce resources, and produce greater operational readiness as 
part of an enhanced training transformation capability. Transformation of courses can be 
usefully supported in having PfP Training Centres and Co-operative Development Teams 
work together, as Turkey plans to do, for instance. 


PfP Training Centres are assessed to be an essential source of insight and guidance on 
the harmonization of curricula and could help in developing and sharing ADL courses and 
joining in Distributed Simulation Command Post Exercises (CAX) under the auspices of 
the PfP Simulation Network, or in a Distributed Defence and Wargaming Simulation 
approach in tandem with the PfP Consortium. In support of the NATO-PfP ADL and 
Distributed Simulation effort, NS(O) could be strengthened to perform a ADL/SIM 
clearinghouse function among the PfP Training Centres and provide another mechanism 
for including Partner nations in the Transformation agenda. 


PfP Simulation Network 

The PfP Simulation Network initiative has developed on a regional-basis (e.g., Southeast 
Europe Simulation Network (SEESIM), Baltic Simulation Network (BALTSIM), et al), 
joining in mutual collaboration approximately twenty Nations. Like the ADL effort, where 
one Partner nation (Switzerland) has led the effort in mentoring other nations, Sweden has 
been at the forefront in developing and promoting Distributed Simulation as a core 
capability connecting Allies and Partners, employing in particular the “Viking” series of 
exercises. This effort, however, is not presently linked with any NATO permanent office to 
distribute simulation and this is another area of ongoing activity that is of great potential 
benefit to the Allied Command for Transformation. 


Transformation: Building Upon Complementary Efforts to Attain New Synergies 
The Prague Summit Declaration statement concerning cooperation with the EAPC/PfP 
countries directs that “Allies, in consultation with Partners, will, to the maximum extent 
possible, increase involvement of Partners, as appropriate, in the planning, conduct, and 
oversight of those activities and projects in which they participate and to which they 
contribute.” This means that efforts such as the PfP Consortium, PfP Training Centres, 
and PfP Simulation Network may benefit of greater Partner direction and control. At the 
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same time, a strengthening in the participation and linkage of NATO counterpart activities 
could complement the integration and mutual support effort. Respectively, the NATO 
Defence College, the NATO School (Oberammergau), and the NATO-PfP Distributed 
Simulation Capability Initiative (DSCI) are equally important in the overall transformation 
vision to attain new synergies in the quest for enhanced interoperability and strengthened 
security cooperation throughout the Euro-Atlantic region. 


MAIN CONCLUSIONS 
On Advanced Distributed Learning: 


ADL capability has enormous potential. The NATO / PfP ADL Program can contribute to 
further increasing readiness by providing high quality, interoperable, and sharable 
education and training anytime and anywhere, while improving military effectiveness and 
efficiency. ADL might become a prerequisite to attending a course, thus ensuring the 
proper level of training has been reached by the trainees. The Sharable Courseware 
Object Reference Model (SCORM) concept provides a basis for the development of ADL 
modules to be freely shared among institutions and nations in support of interoperability 
and reusability. The NATO/PfP ADL prototype has provided an immediate ADL capability 
to NATO and PfP nations, resourced by Voluntary National Contributions (VNCs)._ In 
particular, the “Introduction to NATO” - the first course in the prototype — has been 
considered by users as useful, well prepared, and an excellent way to introduce, refresh or 
update students on that subject. In general the ADL Prototype has been assessed as 
easy to use and valuable; moreover, there is a strong request for the provision of more 
courses. The establishment of a permanent Operational NATO/ PfP ADL capability 
supporting PfP and also NATO education and training is feasible. The ADL prototype 
should be extended, resourced by VNCs, to form an Initial Operational Capability that will 
continue providing an immediate ADL capability and service to NATO and PfP nations, 
and will form the basis for specifying the procurement, via standard NATO Capability 
Package procedures, of an Operational NATO/PfP ADL Capability. 


To meet the request for new ADL material the national Co-operative Development Teams 
(CDT), trained under the auspices of US-Swiss support to the PfP Consortium of Defence 
Academies, have to continue their crucial activity of transforming traditional courses into 
ADL supported courses. It is also anticipated that NATO and PfP Educational Institutes 
should become producers of ADL courses and material. There is a need to enhance the 
ADL capability of NATO education and training organisations. The establishment of ADL 
”Chairs” in NDC and NS (O), as well as one Co-operative Development Team for both 
Institutions are key factors to harmonise ADL work and populate their portal. This 
capability should be provided as part of a new VNC in terms of the provision of qualified 
technical personnel in support of PSE’s devoted to TEEP ADL/SIM implementation, with 
equal contributions from both Allies and Partners. The future Operational ADL capability for 
NATO/PfP Education and Training should be located at ACT and supported by NATO 
Education Institutes (NDC, NS (O), NCISS), PfP Training Centres and the PfP Consortium 
of Defence Academies. The training provided by these institutions and their requirements 
varies considerably, and it is more effective to achieve ADL capability by establishing each 
of these organisations and PTCs as “Centres of Excellence” in NATO/PfP ADL. 
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Development and administration of a common knowledge portal, will be a continuous 
requirement. 


The continuing use of Voluntary Contributions is assessed as being instrumental for 
success until a clear definition of a capability package (CP) can be made for ADL and 
Simulation. Contributors in the development of the ADL prototype deserving a particular 
mention are: 

The PfP Consortium of Defence Academies and Studies Institutes that delivered, through 
support provided by Switzerland and the US ADL Co-lab (employing the SCORM 
standard), the technical tools for the highly successful NATO/PfP ADL Prototype. 
Switzerland whose wider involvement through its support to the PfP Consortium of 
Defence Academies has been a critically important element in the NATO-PfP ADL success 
story. 


A permanent establishment of a NATO-PfP ADL Advisory Board should be a priority task, 
with relevant NATO educational and training institutions drawn into a supporting 
framework with TEEP PfP activities, as well as with key National representatives who may 
be involved in providing Voluntary National Contributions. Allied Command for 
Transformation should develop and co-ordinate appropriate terms of reference for MC 
endorsement. 


It is also noted that some of the PfP countries do not yet have the desired level of Internet 
access, particularly in the Caucasus and Central Asia. It has been identified that this 
concern might be met in using the Virtual Silk Highway Project. Collaboration with the 
Virtual Silk Highway Project through the National Research and Education Network, as 
well as exchange of information between the IMS and the IS Public Diplomacy Division 
should therefore be continued. 


On Modelling and Distributed Simulation: 


There is a requirement, expressed by PfP Nations, for NATO to sponsor a formal 
programme that assists Partners to facilitate their capability to participate in NATO-led, 
Non-Article 5 operations. The envisioned programme will provide training and education 
up to and including in a Combined Joint Task Force (CJTF) staff. This will benefit NATO 
as well. 


It is technically feasible and highly desirable to meet this requirement through the conduct 
of NATO-led, combined joint exercises using distributed CAX and associated ADL to a key 
number of PfP Staffs and Simulation Centres. 


NATO does not currently have an exercise programme which is sufficiently 
comprehensive to provide the opportunities or infrastructure as stated above. 


A formal phased NATO/PfP ADL and Simulation programme could be implemented by 
integrating existing NATO resources with additional identified VNCs, which will provide 
cost-effective training opportunities for Partners to develop and practice NATO-PfP 
Interoperability for combined and joint operations using distributed CAXs, with ACT being 
in best position to provide oversight. 
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ACT, as the Allied Command for Transformation, with the support of NATO Education 
Institutions, such as NDC, NS (O), and NCSIS, is best suited to be responsible for the 
creation and maintenance of the overall NATO-PfP Training and Education Programme, 
including ADL and Simulation efforts. 

Experience gained during the development of the first phase of that NATO-PfP Training 
Programme could form the basis for ACT to specify the procurement, via standard NATO 
procedures, of an Operational Capability for NATO and PfP which integrates NATO/ PfP 
Distributed Simulation to a future Leadership Staff Training Programme (successor of 
ACSTP). 


On the links between NATO and the PfP Consortium of Defence Academies: 

A recommendation on the revision and strengthening of this link will form part of the 
Progress Report on TEEP that will be provided as NMA advice in the framework of the 
preparation of the Spring Ministerial. 


The NDC role as NATO’s focus with the PfP Consortium has proven useful in keeping 
NATO apprised of the activities of the Consortium. NDC’s active involvement in 
participating in numerous working groups, in particular the Secretariat Working Group, has 
likewise helped the Consortium. NDC should continue to represent NATO in any 
deliberations concerning the evolution of the Consortium, especially in regard to the 
NATO-PfP interface on educational and research requirements. 


The NDC, in collaboration with the PfP Consortium of Defence Academies, should become 


responsible for ADL course contents at the strategic and political-military education level, 
as depicted below: 


PfP Consortium and NATO 


Defence 
Academies 


PfP Consortium 


Official NATO 
Relation 
ADL node 


On the links between NATO and the PfP Training Centres: 
The NS (QO) in collaboration with PfP Training Centres should become responsible for ADL 
course contents at the military operational training level. 
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The NS (O) role in relationship to PfP Training Centres should be strengthened with the 
view to facilitate the integration of operational training and educational requirements in 
support of ACT (Allied Command for Transformation). 


The PfP Training Centres are assessed to be an ideal source of insight and guidance on 
the harmonisation of curricula and producers of ADL material. 


PfP Simulation Centers and NATO 


PfP TRAINING => 


CENTERS 


Official NATO 
Relation 
SIMNET & 
ADL node 


On the links between NATO and the PfP Simulation Network: 

Allied Command for Transformation (ACT) should establish a NATO-PfP Distributed 
Simulation Capability Initiative (DSCI) and a Programme Office to be responsible for 
Distributed Simulation issues at both the strategic and operational level. DSCI should 
integrates NATO/ PfP Distributed Simulation to a future Leadership Staff Training 
Programme (successor of ACSTP) 


The ACT DSCI office should work in collaboration with the NDC and the PfP Consortium in 
exploring opportunities to strengthen defence gaming and simulation capabilities at the 
strategic level. 

The ACT DSCI office should work in collaboration with the NS (O) and the PfP Training 
Centres in exploring opportunities to strengthen distributed simulation capabilities at the 
operational level in support of the CUTF concept. 


The figure below shows how the Simulation Centres might be interlinked with NATO. 
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On the structure: 

ACT should become the single focus for NATO and PfP ADL and Simulation in NATO and 
responsible for the creation and maintenance of the NATO-PfP Training and Education 
Programme, maintaining a close collaboration with SHAPE. 


ACT should establish a core capability to implement the ADL strategy and to provide 
guidance in Distributed Learning and Simulation and to be the permanent organisation to 
administer, manage and co-ordinate ADL & Distributed Simulation in NATO and 
harmonise with PfP Nations and PfP Training Centres. 


The key agencies, infrastructure and processes might be interlinked as follows: 
Mutual Support Activities 
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WAY AHEAD 


On Advanced Distributed Learning. 

The ADL prototype established under ACT has been evaluated throughout 2002 thanks to 
National Contributions from Allies and Partners, and with the continuous support of 
RTA/NMSG. It has been concluded that the prototype is valid, and NATO therefore 
recommended the development of a permanent TEEP ADL capability in support of 
NATO/PfP Education and Training. 

ACT and SHAPE have been requested to make proposals regarding the development of a 
capability package by Spring 2004, that could be implemented mainly through the 
continuation of current VNCs. 


On Modelling and Simulation. 

ACT and SHAPE analysis concluded distributed simulation has an important potential to 
facilitate the training of staffs, up to CUTF level and to contribute enhancing interoperability 
at lower operating costs. Currently, a number of national realisations, such as VIKING, 
BALTSIM or SEESIM exercises could meet PfP requirements up to multinational brigade 
level. However there are no existing opportunities at the Component Command and CJTF 
levels. 

Establishing a complete NATO/PfP simulation capability at all training levels would go far 
beyond NATO’s investment capabilities. Therefore, existing national realisations should be 
used through specific agreements. To this end, as a trial, NATO will be represented in the 
next VIKING exercise in December 2003. 

NATO could concentrate on the establishment of a specific simulation capability at the 
CJTF level, and support lower operational levels. It has been assessed that such a 
capability should be feasible and affordable. 

ACT and SHAPE have been requested to make proposals regarding the development of a 
capability package, together with a set of distributed NATO prototype exercises by Spring 
2004. 


CONCLUSION 


Considerable interest has been addressed to TEEP since the Washington Summit. The 
Prague Summit, known as the “Capabilities Summit” paved the way for implementing the 
programme, in re-endorsing it. 


The International Military Staff has now nearly completed the policy part of the work, 
thanks to the contribution of a team of many NATO and Partners individual and bodies, 

of which ACT, the NDC, the NS(O), the US JFCOM, the Swedish Wargaming Centre, the 
RTA/NMSG and the International Staff contributions have been instrumental for success. 


ACT and SHAPE are currently devoting considerable efforts in developing capability 
packages for ADL and for Simulation sub-components, so that this becomes reality. 


They can only have success if real commitments are decided between NATO, ΡΙ͂Ρ, 
regional and national contributions. 
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RESUME 


Le déploiement en cours du SIR, Systéme d’Information Régimentaire (SIR) destiné a couvrir a la fois le 
niveau régimentaire (Bataillon) et unité élémentaire (Compagnie), implique de revoir rapidement les 
méthodes de formation et d’entrainement. En effet, les exercices d’entrainement actuels et les 
architectures de CAX ne sont plus adaptés, puisqu’ils ne prennent pas en consideration la valeur ajoutée 
apportée par les systémes C4I. Ils ne permettent pas, par exemple, de stimuler le SIR avec des données 
appropriées pour le (41. ESTHER, acronyme pour "Environnement Synthétique de THeédtre pour 
l’Entrainement des PC Régimentaires", est un Programme d’Etude Amont (PEA) piloté par la DGA. Il a 
pour objectif d’étudier la faisabilité de doter l’armée de terre d'une structure d’accueil de type plug-in 
permettant la connexion nationale et multinationale de C4I et de systémes de simulation HLA distribués et 
offrant des services pour la préparation, l'exécution et l'analyse des exercices d’entrainement. Pour le 
PEA ESTHER, l’exigence primordiale de l’armée de terre consiste a faire communiquer entre eux les 
modeles de simulation existants et les C4I actuellement déployés, pour satisfaire ses besoins de formation 
et d’entrainement. ESTHER s’attache donc particuliérement a l’interopérabilité entre le SIR et JANUS 
HLA. Des résultats convaincants ont d’ores et déja été obtenus dans le domaine de |’interopérabilité entre 
C4I et systémes de simulation, abordé selon l’approche en deux étapes suivante : 


e La premiére étape concerne la configuration des systemes de simulation et des C4I avant leur 
déploiement et leur utilisation. Cette étape comprend I’identification et la mise a disposition des 
données pertinentes a partager, permettant ainsi d'assurer Vinteropérabilité dite statique. Dans le 
domaine opérationnel, les données statiques telles que l’ordre de bataille, la position initiale des 
unités et leurs ressources, les réseaux de communication tactique et les lignes de coordination doivent 
étre identiques pour les deux types de systémes. Dans le domaine technique, |’interopérabilité 
statique concerne la configuration du temps de référence, les adresses de messagerie des C4I, les 
adresses IP des systémes informatiques, les fichiers de configuration des fédérés et des routeurs. 
Actuellement, les données statiques du domaine opérationnel sont disséminées entre les systémes de 
simulation et les C4I, et l'initialisation de ces derniers implique un processus de distribution sélectif. 
Jusqu’a présent, les systémes de simulation et les C4I ont été concus selon des filiéres bien sépareées. 
Leurs standards d’échange respectifs ne sont pas compatibles, ce qui impose la réplication manuelle 
de l’information d’un systéme a un autre. Ces opérations prennent du temps, consomment de la 
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ressource et introduisent des risques d’erreurs dues a de mauvaises interprétations. Des mécanismes 
doivent donc étre mis en place pour automatiser la configuration commune des systémes de simulation 
et des C4I. 


e La seconde étape concerne la connexion bidirectionnelle et la coordination entre systémes de 
simulation et C4I durant l’exécution de la fédération, permettant ainsi d'assurer Vinteropérabilité dite 
dynamique. Du point de vue opérationnel, cela signifie que les C4I doivent pouvoir émettre des 
ordres aux unités subordonnées (i.e. unités simulées) et recevoir en retour leurs comptes-rendus issus 
de l'environnement simulé (position des subordonnés, état des mines, données logistiques, ...). Cela 
signifie également que les activités des deux systémes doivent pouvoir étre controélées et 
synchronisées. D’un point de vue technique, I’interopérabilité dynamique impose une compréhension 
commune du champ de bataille numérisé afin de disposer d’une information cohérente, et l’utilisation 
de standards d’échange identiques pour la communication de l’information entre ces systémes. Le 
modele de données des C4I et les modéles de données des systémes de simulation (et de la fédération) 
doivent converger, ou au moins se recouvrir partiellement, faute de quoi l’interopérabilité n’est pas 
envisageable. Aujourd’hui, des passerelles sont utilisées pour traduire et mettre en correspondance 
Vinformation entre les systémes. Cependant, ces passerelles sont congues pour fonctionner dans un 
environnement déterminé et doivent en outre suivre les évolutions des C4I. C’est pourquoi au-dela de 
l’alignement des modeéles de données, il semble indispensable pour l'avenir d’aligner également les 
architectures en partageant des modules communs. 


Ce "papier" présente dans le détail les difficultés introduites ci-dessus, il décrit les solutions telles qu'elles 
ont été implémentées dans ESTHER, puis il propose un apercgu des prochains travaux qui seront 
accomplis dans la suite du PEA dans le domaine de I’interopérabilité entre systémes de simulation et ( 4]. 
La présentation s’achéve avec une synthése du retour d’expérience de l’exercice DEFTEMP conduit a 
l’EAI en mai 2003. 


OVERVIEW 


The newly fielded French Regimental Information System (SIR), covering both Battle group (Battalion 
Level) and Elementary units (Company Level), urgently requires an improvement to the current education 
and training methods. Previous training courses and CAX architectures are no longer suitable as they do 
not take into account the added value provided by C4I systems. They do not stimulate SIR with 
appropriate C4I data. ESTHER (Acronym for "Environnement Synthétique de THédtre pour 
l’Entrainement des PC Régimentaire") is a French MoD R&T program. It is dedicated to exploring the 
feasibility of providing the French Army with a plug-in framework allowing national and nation-wide 
connections of distributed C4I and HLA Simulations and offering services to achieve preparation, 
execution and analysis of training courses. The highest priority Army requirement is for ESTHER to 
bridge the gap between the legacy Modelling and Simulation tools and fielded C4I systems to support 
Army education and training activities. Moreover, ESTHER addresses the interoperability between SIR 
and JANUS HLA. Beneficial results have been obtained in the area of M&S and (41 interoperability 
according to the two-stage approach below: 


e The first stage is the configuration of M&S and C4I systems prior to their deployment and common 
use. This stage covers the identification of the relevant, shared data and distribution. This is called 
static interoperability. In the operational area, static data like order of battle, terrain, initial units 
location & resources, tactical communication network and operational limits have to be consistent in 
both systems. In the technical area, static data covers the configuration of reference time, C4I Mail 
addresses, systems IP addresses, network masks, RTI (rid file) and routers. Currently, the operational 
static data are shared out between M&S and C4I systems and their initialisation imposes a selective 
distribution. Up to now, as M&S and C4I were developed along separate tracks, interchange 
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standards are not compatible. This usually forces manual replication of information from one system 
to another. Those operations are time and resource consuming and introduce risks of errors due to 
wrong interpretation. Thus, mechanisms have to be developed to automate the common configuration 
of M&S and C4I systems with appropriate data. 


e The second stage concerns the bi-directional connection and the co-ordination between M&S and C4I 
systems during the federation and C4I execution. This is called dynamic interoperability. From the 
operational point of view, it means providing the capability for C4I to send orders to its subordinate 
units (i.e. simulated units) and to receive reports from the M&S world (subordinates location, 
minefields status, logistic data etc.). It also means providing control and synchronisation of both 
systems activities. From the technical perspective, dynamic interoperability implies a common 
understanding of the digital battle space in order to handle the information consistently, and the use 
of the same interchange standard to carry the information between both systems. The C4I Data Model 
and the Simulation/Federation Object Model must converge, or at least partially overlap, otherwise 
no interoperability could take place. Currently, gateways are used to translate and map the 
information between systems. However, those systems are made to run in a limited environment and 
must cope with the improvements of the legacy C4I. That is why, beyond the alignment of data models, 
it appears mandatory in the future to align the architecture by sharing a common structure. 


The paper describes in more details the issues introduced above, depicts the current solutions 
implemented in ESTHER and gives an insight into the next ESTHER M&S and (41 interoperability 
studies. It concludes with the lessons learnt from the DEFTEMP Exercise held at EAI (Ecole 
d’Application de I’Infanterie) in May 2003. 


1.0 INTRODUCTION —- BACKGROUND 


1.1 SIR overview 


The SIR (Regimental Information system) is the French Army C4I covering both Battalion and Company 
levels. This information system equips Army Combat, Combat Support (Engineering and Artillery) and 
Combat Service Support (Logistics) units. 

It is interconnected with the following French Army C4I systems : 


e SICF (Communication & Information system of the forces) which operationally equips the Army 
Brigade and Division levels, 


e the LECLERC information system already fielded, 


e ATLAS (Automation of Fire and Connections of Ground-to-ground Artillery) which will replace in 
the short term the current system ATILA for the artillery chain, 


e the future SIT (Terminal Information System) which will equip all the army units at section level in 
2008. 


The communication between the previous systems is based on the SICAT Army electronic message 
format and the XL message text format. Communication networks within the SIR are ensured through the 
PR4G (Radio Set 4th Generation). 


The SIR is mainly installed in the VAB (Forward Armoured Vehicle) with a single or a double 
workstation configuration. 


1.2 Training and Education with SIR 


The newly fielded SIR requires an improvement to the current education and training methods for the 
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personnel of the Command Post (CP). It is indeed necessary to take into account the added value of the 
system on the command process. Mentality will have to evolve to substitute data processing for the paper 
map to support the decision making process. 


Du to the amount of information to be handled, it is not easy to create an attractive education course for 
the pupils. The first SIR education courses are relatively academic and theoretical, in order to give a good 
vision on the wide spectrum of the system. However, the SIR pupils key concerns are obviously the 
tactics, and it is difficult to demonstrate the SIR added value on the command process with a "static" or 
low interactive education course. 


The SIR training issue is a stumbling block as this system is perceived by the users as a constraint due to 
the amount of information that have to be introduced during an engagement. CP officers are reluctant to 
use it because the system changes their current habits and seems to add workload. 


Thus, both for education courses and training exercises purposes, it appears mandatory to propose to the 
SIR pupils or trainees a tactical environment as realistic as possible allowing the automatic "stimulation" 
of the SIR. 


NB: the use of the SIR will probably never replace voice communications, particularly important and 
critical during the combat. 


13 SIR Usability 


The tasks to be achieved at CP level are schematically the following : 


e Reception and processing of Operation Orders (OPO) and Fragmental Orders (FRAGO) from the 
superior, 

e Generation and transmission of OPO and FRAGO to the subordinates, 

e Generation of requests for information to the subordinates, 

e Reception of the Reports from the subordinates, 

e Update of the Operational Picture, 


e Generation and transmission of the reports to the superior. 


These tasks could be achieved more effectively with the use of the SIR. Are not software Copy and Paste 
the most common used functions as they help saving time ? Before reaching this point, it is necessary that 
the officers gain enough confidence in the system to decide to move from the paper maps to the computer. 


1.4 SIR Stimulation objectives 


The aim of the battlefield digitisation allowed by the C4I chain is to automatically feed each C4I system at 
any level with information coming from subordinate units, reducing the tiresome activities related to 
operational picture building and allowing each commanding level to concentrate on operational 
capabilities. 


In the SIR training and education area, the stimulation allows to initialise the data flow, populating the C41 
system at Company level with information from the synthetic forces in JANUS. The reduction of this 
tiresome activities previously devoted to the SIR pupils or trainees, allows them to focus on the 
operational capabilities (operational message system, operational picture management, and information 
management) Hence, they have more time available for tactical tasks (analyse the information, take 
decision and send appropriate orders). They can discover the added value of the C4I system, gain 
confidence and get convinced time after time to move from paper and manual tasks to computer. 


This concept of stimulation implies to address the issue of C4J-Simulation interoperability detailed in 
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§2.0. 


2.0 C4I-SIMULATION INTEROPERABILITY ISSUE 


Various approaches were proposed to conceptualise the C4I-Simulation interoperability issues. The 
approach retained within ESTHER covers two stages: 


e Static interoperability which deals with the configuration of both systems before execution, 


e Dynamic interoperability, which deals with the bi-directional connection between the C4I and 
simulation systems and with their co-ordination, during run time. 


This approach is presented below for C4I-Simulation interoperability in general, before being instantiated 
for the particular SIR & JANUS case in section 3.0. 


2.1 Static interoperability 


This stage consists in configuring the simulation and C4I systems before execution. Relevant (technical 
and operational) data have to be identified, shared and appropriately distributed to each system. 


2.1.1 Data Identification 


In the operational area, the initial configuration data shared and needed by C4I and simulation systems 
are as follows: 


e The Terrain: It includes data relating to the theatre of operation. The availability of data bases is a 
first issue. However, it is much more a financial and calendar concern than a technical one. In fact, 
different sources and data formats are available as well as editors to modify such data. The 
consistency is a second issue. Terrain data must be consistent even if the aggregation level of the data 
handled by the two systems are different. As an example, elevation and planimetry must be the same 
whatever the systems so that the line of sight function provides consistent results. 


e The Order of Battle (OQRBAT): This is the organisation of the fielded friendly and opposite forces, 
with different representations according to the C4I and simulation needs. On the C4I side, the 
representation must be compliant with the hierarchical organisation. In addition, the naming 
conventions and the operational symbolic are very important. The ORBAT may evolve during the 
engagement with possible reinforcements, and must be displayed with an aggregation level consistent 
with the CP level in the hierarchy. On the simulation side, the key point is to define an organisation 
allowing the creation of simulated units, their characterisation with physical, dynamic and behavioural 
models, their assignment to the simulation operators. If every forces and units must be defined on 
simulation side, it is not mandatory on C4I side. The discovery of unknown units may happen in real 
time and must be identified on case to case as single elements out of the conventional ORBAT. 


e Tactical information: Initial information comes from the OPO: co-ordination lines, reports lines, 
forbidden areas etc. These data constitute guidelines which must be consistent between C4I and 
simulation systems in order to prevent misunderstanding between pupils/ trainees and subordinates 
managing simulation units. Initial information deals only with the friendly forces. Information relating 
to the opposite forces is an assumption of the enemy mission, strength or location. The consistency 
between C4I and simulation is required but not mandatory. 


e The initial situation: This defines the initial location of friendly units, and their first stages of 
displacement. The accuracy of the location is not essential for C4I which usually displays aggregation 
of units, but is mandatory on the simulation side which must also include all the data describing the 
friendly and the opposite forces. Lastly, an initial planning of the displacements for the units can be 
defined before the beginning of the run, in order to speed up the exercise launching phase. 


e Initial Resources: This part deals with Combat Service Support (human and material supplies as 
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food, ammunitions, fuel, etc). Initial resources must be consistent between C4I and simulation 
systems. From the C4I point of view, this information is managed inside logistics arrays to request 
supplies when the limit of the consumption is reached. On simulation side, these data are mandatory 
for the models and to generate relevant reports towards the C4I (See §2.2). 


e Tactical Communication Networks: The realism of the tactical communication network is more and 
more requested from military personals for training purposes. Operational and physical characteristics 
of communication networks for data transmission must be taking into account. As an example, the 
organisation of the network with relay elements, range, frequencies and status of operational devices, 
the conditions of propagation, must be modelled. Units equipped with C4I systems have to be 
identified in the simulation. At the end, the simulation must shared with the C4I system the network 
topology, the users and operational addresses. 


e Mailing system: Exchange of operational messages are usually performed via a mailing system. It is 
mandatory to share the operational user directory between C4I and simulation. 


In the technical area, the initial configuration data shared and needed by C4I and simulation systems 
information are as follows: 


e Information networks: The C4I network and the simulation network have their own configuration 
parameters. Most of the time, those parameters must be modified to allow communication between 
C4I and simulation systems: changes in IP addresses and masks, declaration of addresses (hosts file), 
declaration of the default gateway and routers. The technical configuration of C4I is made once for all 
when the system is delivered to the forces according to technical military guidance. Changing C4I 
parameters thus implies the reversibility and the flexibility of the system. 


e Space-time References: C4I systems have their own time management and location means, based 
more commonly on GPS (Global Positioning System) and they work in real time (BRAVO, 
ZOULOU). On simulation side, the time is set up when the simulations are launched. In addition, the 
time could evolve differently than real time. In the case of a training exercise for instance, the exercise 
may go faster for pedagogic objectives. Then the C4I time is usually no longer suitable with the needs 
of the exercise. Now, as adequate temporal information is essential for the time stamping of 
operational messages, the C4I time has to be managed by simulation from the beginning of the 
education course or training exercise. 


The identification of the SIR-JANUS static interoperability data is detailed in 83.3.1. 
2.1.2 Distribution of the data 


The technical and operational data having been identified in the previous section, it is necessary to make 
them available to both systems, C4I and simulation. 


The data must be distributed to both systems, in accordance with the needs and specificity of each one: 
e ΟἽ] are characterised by an organisation, hierarchical levels and manning, 
e Simulations are characterised by simulated units (more or less aggregated) and associated resources 


(fuel, ammunition, personals). 


C4I and simulation systems having been developed in very different manner, the semantic correspondence 
between them is not immediate: Hierarchy (Battalion, Company, etc) and Organisation (armoured, 
infantry, etc) are not consistent a priori. As an example, the Company can be called Battery or Squadron, 
according to the organisation concerned. 


Under these conditions, manual transfer of information from one system to another is the obvious solution. 
However, it needs man power, it is time-consuming, and errors may occur due to wrong interpretation. In 
addition, for each modification in one system, it is necessary to check and make the corresponding 
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modifications into the other systems. 


To solve the previous issues, it is then easier to create mechanisms which will facilitate the common 
configuration of C4I and simulation systems for education and training purposes. Such a mechanism 
includes: 


e the definition of one or several data interchange formats (DIF). This is already the case for terrain with 
SEDRIS. But SEDRIS is not used by the C4I community which prefers VMAP and DTED files 
format. Besides, SISO papers mentioned attempts for the definition of a DIF ORBAT, without any 
standards so far. However, interchange format are still missing for the transfer of tactical information 
as for instance operational overlays, initial forces situation and resources. The use of a standard 
language for the data exchange, as XML (Extented Mark up Langage) which is very flexible and 
easily readable with many freeware tools is a solution to recommend. 


e the definition of rules (who provides what 7). C4I systems could be the provider for operational data. 


e and, finally the organisation of exchanges when the overall information needed is completed. The 
creation of a conductor to collect, map, achieve the consistency of information before distribution is a 
solution to explore. 


The mechanisms developed for distribution of data between SIR and JANUS through ESTHER are 
detailed in §3.3.2. 


2.2 Dynamic interoperability 


This second stage addresses the running of an education or training federation. It takes into account the bi- 
directional connection between C4] and simulation systems according to operational and technical point of 
view. 


2.2.1 Operational issues 


The aim is to allow the CP officers to use their C4I system in the most realistic and efficient manner. It 
means that the concept of stimulation explained in section 1.4 must be fully implemented as describes 
below: 


e Sending Orders to the subordinates (i.e. to the simulated units). Two possibilities have to be 
considered. The first and easiest way is for the subordinate units to own a C4I same as or interoperable 
with the training audience's C4I. The second approach is at the simulation level to be able to extract 
from the OPO the most important elements to drive automatically simulation models. It means for the 
latter that the simulation can capture the operational message and knows how to decode the 
information. To deliver the message to the simulation side, the trainee must send it to a virtual C4I 
system (i.e. the simulation) referenced in the Mail user directory. 


e Sending Requests for information to the subordinates. The approach is the same than above. 
However, the message processing could be more or less automated. As an example, if the request is to 
obtain the logistic status of the subordinate units, the answer could be sent automatically from the 
simulation. Again, it is mandatory to share the same Mail user directory. 


e Receiving subordinates reports: it deals with the location of the subordinates units, their status and 
the status of the obstacles etc. Those messages may be sent automatically from simulation at fixed 
time as in real live. They may also be generated by the simulation operator when it is needed by the 
hierarchy. 


Finally, the operational issue addresses the control and the synchronisation of both C4I and simulation 
systems. It mainly deals with the time as discussed in section 2.1.1. Thus, (41 must be managed by the 
federation as "time constraint" federate. Of course, C4I will never be time regulating. This last 
requirement is useful when exercise is frozen or must be restarted at a certain time. 
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2.2.2 Technical issues 


From the technical point of view, the bi-directional interoperability must be considered as detailed below: 


e The Simulation-to-C4I connection: the generation of messages toward the C4I is quite simple to 
perform for most of them. The process consists in capturing from the HLA flow the data necessary for 
CA4I, assembling them according to the appropriate message format, and sending this message to the 
C4I according to the shared Mail user directory. However, the synthesis or the aggregation of the 
information to the higher level of command can be a more demanding task. Thus, algorithms must be 
the same in ( 4] and simulation systems to keep the operational consistency. 


e The C4I-to-Simulation connection: the issue is really more complex. The operational message 
information must be extracted (order or request) and made understandable for simulation. For the 
OPO (which contents a lot of free text), the orders assignment to the simulated units constitute a major 
stumbling block. It requires operational expertise in order for the simulated units to execute the right 
mission. 


For both type of connections, the interoperability implies a common understanding of the digital battle 
space in order to handle the information consistently, and the use of the same interchange standard to 
transfer the information between both systems. The C4I Data Model and the Simulation/Federation Object 
Model must converge, or at least partially overlap, otherwise no interoperability could be forecast. In fact, 
it means that the way to describe an operational object in both systems must be the same or must be close 
enough to be able to identify common attributes with same meaning. For interchange standard, it is 
recommended for the simulation to use the same mailing system than the C4I. 


Currently, gateways are used to translate and map the information between C4I and simulation systems. 
Their use presents the following drawbacks: 


e The semantic translation happens only for very structured simple messages. For more complex 
messages such as OPO, it would be mandatory to use special keywords in free text fields that could be 
recognised by the gateway. 


e These gateways are designed to run with a list of systems. Whatever the interface improvements of 
one of these systems, the gateway must be adapted. 


That is why, beyond the alignment of data models, it also appears mandatory in the future to align the 
architecture of C4I and simulation systems. In the meantime, the gateway approach seems an interesting 
palliative solution, on the one hand to ease C4I and simulation interoperability while no standards, 
common architecture and data models are defined, and on the other hand to help improving the C4I- 
Simulation interoperability requirements. 


3.0 ESTHER 


The main recommendations highlighted in section 2 come from the ESTHER R&T program. The 
proposed solutions to bridge the gap between C4I and Simulation systems were developed ant tested 
within ESTHER. The lessons learnt are detailed below, after a brief presentation of the main features of 
ESTHER. 


3.1 ESTHER Overview 


ESTHER "Environnent Synthétique de Théatre pour I'entrainement des PC de Régiment" is a Research 
and Technology Program launched by the DGA (Délégation Générale pour |’ Armement) in 2001. 


ESTHER is a framework allowing the connection of live, virtual and constructive simulations and ( 4] 
systems. ESTHER provides services to configure, manage in real time and prepare after action review for 
education courses and training exercises. Data consistency, C4I-Simulation interoperability and RTI 
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optimization for distributed connection are also studied and demonstrated within ESTHER. 


The objectives of ESTHER are of two types: 
e Operational objectives divided into: 
> Distributed training on several sites, 


> Reduction of the man power and the time required to conduct and configure education courses and 
training exercise, 


> Increase of the operational realism, 
> Remote pedagogy and distributed debriefing, 
> Training at home station. 
e Technical objectives divided into: 
> Use of the French C4I system, SIR, 
Development of HLA interfaces for JANUS and GESI simulations, 
Simulation of operational data networks, 
Automation of the C4I-simulation connection via SICAT and HLA, 


Experimentation of a Federation (ESTHER FOM) where JANUS, GESI and SIR must run all 
together. 


VV V WV 


The ESTHER program is divided into three stages over 4 years. The two years first stage, ESTHER 
G1V1, is now completed with experimentations performed early 2003. The second stage, ESTHER G1V2 
will be finalised in 2004. The last stage ESTHER G2 will address the full program objectives and will be 
tested during a real Battalion exercise in 2005. 


3.2 ESTHER G1V1 Main Studies 


ESTHER G1V1 studies addressed the following topics: 
e The development of an HLA plug-in framework, 


e The implementation of an HLA interface for JANUS, based on RAL. 
Note : RAL (RTI Abstraction Layer) is a tool suite developed by the ANPROS (French Navy 
Operational Research and Simulation Centre) including a FOM independent library used as a 
middleware between the RTI and the simulation code. 


e The development of models for tactical data network, 


e The realisation of an interoperability gateway between SIR and JANUS. 


The scope of this document is limited to the explanation of this last item. 


3.3. ESTHER G1V1 C4I-Simulation interop. 


The ESTHER G1V1 interoperability studies between SIR and JANUS are detailed in the sections below 
according to the two-stage approach, static interoperability and dynamic interoperability. 


3.3.1 Static interoperability data 


The operational elements to configure both SIR and JANUS are generated from an ESTHER as a unique 
source. The information for systems configuration managed within ESTHER are detailed below. 


The Terrain: a terrain editor was developed by the CROSAT (Army Operational Simulation & Research 
Centre) to generate JANUS terrain data base, from DTED and VMAP files. Thus, it is possible to generate 
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any terrain needed for JANUS. 


On the ESTHER side, the terrain is a RASTER map easily generated from USRP data, except for junction 
problems which require an extra cartographic tool suites. 


On the SIR side, the RASTER map (re-used by ESTHER) is supplemented by DTED data. 


Under these conditions, the terrain data base must be locally defined within each system. However, the 
name of the terrain is transmitted from ESTHER to JANUS in the "Terrain" section of an export file (see § 
0 ). With this name, JANUS server and its clients are able to download the suitable terrain from JANUS 
data base. Currently, the terrain areas available in ESTHER are Mailly-le-Camp and the surroundings of 
Montpellier. 


The Order of battle: A dedicated ESTHER editor is used to create the ORBAT which comply with the 
requirements of SIR and JANUS. Each node of the hierarchical structure is either a Force or a Unit. For 
Forces, attributes can be defined, such as name, colour, type (FRIENDLY, OPPOSITE, NEUTRAL). For 
each Unit, there is: 


e a specific SIR section including: the level (Company, Platoon, etc), the type (PC or Unit), the 
organisation (Infantry, Cavalry, etc), the speciality (Anti-tank, etc), manning (Officers, NCO, 
Soldiers). 


e aspecific JANUS section where the following information must be specified: the type of platform, the 
logo, the percentage of initial ammunition and fuel allocation, etc. 


An ORBAT library is available, which includes in particular, for the Friendly side, a French BattleGroup 
(GTIA) essentially made of armoured or infantry forces and for the Opposite Force, different formations 
corresponding to a standard enemy. 


This ORBAT is transmitted to JANUS in the "ORBAT" section of an export file (see §3.3.2). This 
ESTHER exchange format is specific, as it was designed jointly with CAE to ensure compatibility with 
GESI. 


Tactical information: A dedicated ESTHER editor is used to define operational overlays with main 
information including Assembly Areas (AA), co-ordination lines, reports lines. Exporting this information 
with the ORBAT is planned in the next ESTHER version. 


Initial situation: A dedicated ESTHER editor is used to set the initial location of the simulated entities of 
the ORBAT (friendly and opposite forces) on the terrain; these positions will be exported to JANUS (see 
§3.3.2). JANUS initial planning (initial displacements) will be defined in the next ESTHER version. 


Initial resources: The following information can be configured from ESTHER: 


e The composition of the crews belongs to the ORBAT. This information is not processed by JANUS 
which only handles entities, but it is exported to SIR. 


e The fuel and ammunition resources are defined in the ORBAT, expressed as a percentage of the initial 
allocation. This information is used by JANUS when the platform is generated. The default value is 
100%. 


Tactical communication networks: A dedicated ESTHER editor is used to create the different data 
communication networks, as the type of protocol to use. Each SIR officer defined in the ORBAT is seen 
as a network node. 


The technical elements to configure both SIR and JANUS are generated from an ESTHER unique source 
as for the operational information. They are detailed hereafter: 


Information networks: A dedicated ESTHER editor (the hardware configuration editor) is used to define 
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information relating to ESTHER federation, which includes: 
e Sites where hardware is deployed, 


e Each hardware item characterised by a name, an IP address, a type, and a mask. 


Depending on the type, additional information is entered: 

e For SIR: SICAT address, 

e Fora JANUS client: its server, 

e The network-type hardware (routers for multisite, Switch for single site). 


The configuration for each hardware component is established in advance. This configuration task is 
inevitably manual. 


Mailing system: The subordinates of the SIR Battalion CP are SIR Companies. Each SIR must thus 
belong to the ORBAT and be linked to a platform. It must have an electronic SICAT mail address, and be 
declared in the SIR mail user directory. Each SIR being declared, it may send and receive messages in 
SICAT format (see § 3.3.3). 


Space-time References: SIR is provided with a time and location reference based on the GPS. In the case 
of an education courses or a training exercise where the terrain and the time could be different than the 
real situation, the GPS is deactivated and the computer clock is configured with the exercise time in 
accordance with the federation time. 


3.3.2 Static data distribution 
When all the previous information are fully defined in ESTHER, they must be sent to the SIR and JANUS. 


According to the approach described in §2.1.2, the distribution of data is handled via a third system. This 
is ESTHER which uses data interchange format and an exchange language, XML. 
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Static Distribution in ESTHER 


The interchange format: As the format used by the SIR to export or import ORBAT is not a DIF format, 
the only concern is the export of ESTHER information towards JANUS and GESI. The ESTHER ORBAT 
being very precise for SIR requirements, the overall information is not required by simulations. As an 
example, the topics as Armoured, Infantry, Artillery, Engineering and Units sub-categories are not 
relevant for simulation. On the other hand, simulations need to know the exact platform name. Both 
JANUS and GESI servers dispatch the ORBAT entities between their clients. As these simulation systems 
own their file format to store the data, ESTHER can not comply with these two DIF and therefore will 
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generate an XML file; each simulation being in charge of completing the translation. 


The exchange language: The XML language is used to export the following information: 


e SIR XML files: Two XML files are generated to describe the Friendly ORBAT, and Opposite 
ORBAT. They comply with the SIR import/export XML format; 


e JANUS XML file: A third XML file is the JANUS and GESI export file which contains various 
sections describing: 


> ORBAT with the initial location for each platform, 

the relations between forces (friendly and opposite), 

the description for each simulation server of the names of its clients, 
the dispatching of ORBAT units between simulation workstations, 
the weather conditions, 


the name of the terrain, 


VV VV V WV 


the time of the federation when starting the exercise, 
> the name of the federation and other HLA information. 


e Distribution of the XML files: they are transmitted via FTP from ESTHER to simulations and SIR. 
For a multisite federation (planed for G2), the use of an ESTHER relay is foreseen. 


e Processing of the XML files: The SIR XML file is processed according to the SIR ORBAT loading 
procedure. For JANUS, a manual processing procedure is started on each JANUS server for data 
import and insertion into the data base. This procedure is mandatory to convert the ESTHER ORBAT 
into the simulation files format (SANUS, but also GESI in next version). 


Once this procedure executed, the education courses or the training exercise can be launched by ESTHER. 
Both ESTHER and JANUS are HLA federates in "regulating" and "constraint" mode. The "RAL Player 
Recorder" ESTHER federate (data logger) is in "constraint" mode only for the replay. 


3.3.3. Dynamic Interoperability 


Considering that the SIR is an operational system that can not be modified without restricted conditions 
and considering the workload already spent to develop a JANUS HLA interface without changing the 
overall architecture, it has been decided to take into account the dynamic interoperability between SIR and 
JANUS via a SIR-Simulation gateway integrated in ESTHER. 


The picture below depicts the principles of JANUS-SIR coupling via ESTHER. 


Tt 
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JANUS-SIR coupling via ESTHER 


The capabilities of this gateway are presented below. 


Gateway: It is a component of the ESTHER basic software and is based on a SIR piece of software This 
component is part of each ESTHER client. It makes it possible to create SIR messages from the 
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information captured from the HLA simulation flow. In addition, this gateway stores every SICAT 
messages exchanged during the running of the federation. 


Exchange format: The HLA objects and interactions are converted into SICAT messages for SIR. 


Generation of messages: The process used to generate SICAT messages is depicted on the diagram 
below. It consists in extracting from the HLA flow the overall information, and encapsulating it into an 
appropriate SIR message selected by an ESTHER operator. The address for the final recipient is selected 
from the shared Mail User Directory. The message generated is finally sent via the SIR network according 
to the SMTP protocol. 


SICAT message generation in ESTHER 


SIR Operational messages: The messages being generated from ESTHER are listed below: 
e Report messages from Company to Battalion: 
SITREP/at a time: Periodic Friend and Opposite Situation Report at a time, 
SITREP/PTSITU: Specific Friend and Opposite Situation Report, 
CRRENS: Opposite Situation Report which belongs to the intelligence chain, 
SITEFF: Situation Report on human resources, 
SYNSAN: Medical Situation Report. 
e Messages from Battalion to Company: 

> INFOSITREF, Friendly: Reference picture for Friendly Forces, 

> INFOSITREF, ENI: Reference picture for Opposite Forces, 

> INFOSITREF, Environ.: Reference picture for environment, 

> INFORENS: Reference picture for the intelligence chain. 


VV VV WV 


e Messages on obstacles (bi-directional): 
> SITOBST REF-:: Reference Situation for obstacles, 
> SITOBST MODIF.: Change of Status for obstacles. 
e General messages: 
> ALARM and END/ALARM 
> GENTEXT: Free text message. 


Message processing by SIR: The messages sent from ESTHER are processed by the SIR in the same way 
as native SIR messages. According to the SIR configuration and the types of messages, the different 
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messages are processed automatically or not, and integrated automatically or not into the Consolidated 
Tactical Picture. 


Operational co-ordination: ESTHER is designed to be the “master” of the federation. Thus, this 
principle is applied as follows: 


e ESTHER starts and freezes the federation according to the following process: as every federates are 
time "regulating", freezing the federation means for ESTHER to never accept time advance grant. 

e Considering the disconnection of the SIR GPS as described above, the SIR operates according to its 
own system clock which is not controlled by the federation. 


With this version of ESTHER, the choice of the federation time is thus imposed by the SIR system time, 
which confers a certain rigidity to the whole system, preventing the capacity of freezing and restarting the 
exercise as wanted. For the next version, an operating system time management service will be integrated 
between the SIR and the federation. 


3.4 Conclusion 


The gateway between SIR and JANUS developed under the umbrella of ESTHER was used during the 
ESTHER G1V1 experiments which took place during the first quarter 2003 in the JANUS centers of the 
Army Infantry School (EAI) of Montpellier and of the Armoured School (EAABC) of Saumur. 


The SIR Stimulation obtained via ESTHER was considered to be very interesting by the two schools for 
different applications. The EAI wished to use ESTHER for its DEFense TEMPoraire (DEFTEMP) annual 
exercise. The ESTHER experimentation to DEFTEMP is detailed hereafter. 


4.0 INFANTRY DEFTEMP EXERCISE 


4.1 Exercise principles 


The "Defense Temporaire" (DEFTEMP) training exercise is held every year at the Infantry School in 
Montpellier. Following the ESTHER G1V1 experiment campaigns, the purpose to deploy ESTHER for 
the DEFTEMP exercise is to use the SIR / ESTHER / JANUS combination to generate an operational 
environment to train captains to command from their SIR embedded inside the VAB (Forward Armoured 
Vehicle). 


Thus, the objectives are to: 


e Simulate the Terminal Information System (SIT), using SIR messages generated automatically from 
ESTHER, 


e Reproduce a realistic SIR environment for the captain, 
e Assess ESTHER limits with a complex JANUS exercise. 


The main features of the exercise are as follows: 


e The trainee group is made of 9 captains, with two captains per VAB and one captain on a SIR ina 
control room. 


e The scenario is intended to oppose a defending Friendly force consisting of a mechanized Battalion, 
with its four Companies leaded by the trainees, to an attacking Opposite force made of two 
mechanized Battalions and one armoured tank Squadron. 


e The whole forces amount to about 1,600 entities and the intended scenario duration is estimated to 5 
hours. 
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42 Assets 
The assets were deployed for both Forces according to the following diagram: 
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Exercise Organisation 
e SIR: one SIR WS for the High controller at Battalion Level, and one SIR WS for each one of the 4 
Company leaders in VAB 
e JANUS: 1 JANUS server for Friendly and Opposite forces and 1 JANUS client for each Company, 


e ESTHER: The server, 1 WS for EXCON, 1 WS for SIR Stimulation, 1 WS for real time Analysis et 
After Action Review, 


e The SIR network between each SIR WS, 

e ©The Simulation network between JANUS WS and ESTHER WS, 

e The SIR Stimulation Network between ESTHER SIT emulation WS and the SIR WS, 
e The Voice networks between SIR CPs and between JANUS operators and SIR CP. 


Operational PR4G communication devices were deployed for its exercise to add realism. 


4.3 Execution 


The exercise was executed according to the planned objectives and program: 


e A week was devoted to the technical building of the exercise; i.e. the configurations were set up for 
ESTHER (terrain and the exercise ORBAT), SIR, and JANUS. The week ended with a rehearsal of 
the exercise. 


e During a second week, the exercise was executed and repeated several times, with the trainee captains 
changing roles: as Unit Leaders or Leader Deputies. 


e At the end of the exercise period, a demonstration was presented to Infantry School (EAI) 
commanding general. 


From a technical point of view, the organisation retained for ESTHER complied with the Infantry School 
requirements: the messages sent to the captains were generated by a single environment controller from 
the DISTAFF. The messages were handled as follows: 


e Report Request by the captain to the section/platoon leader through the tactical voice communication 
system, 


e Message generation request by the JANUS operator to the DISTAFF through the controller’s voice 
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communication network. 


The combination of three ESTHER, JANUS and SIR components for DEFTEMP exercise was a success. 
The lessons are detailed below. 


4.4 Lessons learnt 


Observing the captains’ activities during the exercise made it clearly appear that voice communication and 
the map were preponderantly used by the Unit Leader. Most of the time, SIR was only used by deputy 
officers. 


As the main explanation, the captains put forward that leading the engagement is a very heavy workload. 
They have a feeling that SIR represents an extra workload, since the information is not automated at the 
lower level. Entering information manually on SIR is considered as taking longer than on a paper map. 
Besides, the representation differences between the paper map and the electronic map have a penalizing 
effect. 


This on-the-spot feeling expressed by the trainee captains was analysed by the School officers who made 
the following comments and correction : 


e The SIT system will be deployed in 5 years time. The captain and their SIR will thus be the entry 
point of the digital battle space during this period. 


e Using the paper map can be judged more effective at present, but: 
> the paper map can only be used by the captain, and is of no help for the higher echelon, 
> the C4I value added functions, for the terrain especially, are much effective than those provided 
by the paper map, 
> taking SIR in hand (training) will accelerate the process. 


e So, it is necessary to make an effort to become quite familiar with SIR, and to acquire automatic 
gestures which will allow more time for tactical reflection. 


In addition, the SIR and voice communication combination must be mastered. It clearly appears that using 
SIR must be considered as a three-phase process: 


e Initial deployment of forces, where SIR is preponderant. It should be noted that the Battalion OPO 
must be "physically" presented by the Colonel to his Captains, with whom contact is essential so that 
the major effect intended can be correctly transmitted. 


e Leading the engagement, where voice communication is preponderant, and where the automation 
allowed by SIR should provide a significant support to the Captain. During this phase, the captain 
seeks proximity with his Squad leaders to be aware in real time of any situation changes. In such 
conditions, the deputies can be in charge of the SIR, essentially to follow Friendly and Opposite forces 
locations, with a reporting to the Battalion. 


e Reorganisation at the end of the engagement, where the SIR becomes again preponderant for a 
precise reporting to the Battalion, and transmission of logistic data. 


This information relating to SIR being set forth, the SIR-Simulation connection via ESTHER is now 
analysed: 


e As expected, stimulation through JANUS makes it possible to give the Captains a much more 
stimulating (even stressful) environment than the conventional in-room training environment. 


e Because of their workloads, the Captains have not regularly made requests for reports. Moreover, the 
time necessary for consolidation to the Battalion, and then for distribution to the Companies (Friendly 
and ENI InfoSitRef messages) have resulted in sometimes important time-lags with respect to the 
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current situation provided by voice communication. 


To motivate the Captains by giving them a regular and consistent stimulation, two corrective measures 
have been retained: 


e SIR Initial situation: it must be defined during the initial phase, 1.6. at the end of the reconnaissance 
phase performed by the squads, jointly between the Captains and the Squad Leaders in the captain’s 
VAB, 


e SIR situation updating: the following messages have to be sent as follows : 


> PTSITU messages must be regularly transmitted by default by the DISTAFF, for example every 
30 minutes. 


> The Captain’s PTSITU messages to the Battalion must be transmitted with the same periodicity, 
with a 10 minutes time shift. 


> The Battalion InfoSitRef message will follow the same logic. 


Σ The other messages, especially concerning obstacles, are transmitted as appropriate. 


This very useful operational experience on the Captains’ training, derived from the DEFTEMP exercise, 
will be used to improve the capacities of the next ESTHER version, more particularly from the SIR- 
Simulation coupling point of view. The outlines are described below. 


5.0 WHAT IS NEXT 


In accordance with the incremental logic of the project, the next version, ESTHER G1V2, will evolve 
according to the functions identified as necessary from the lessons learnt during the experiments and the 
DEFTEMP exercise. 


5.1 New capabilities 


Among the new functionalities (except the gateway), the following topics will be considered: 

e Miultisite: Practical application of study results, with the implementation of gateway federates, 
e New federate: GESI simulation, 

e Logistics: attrition of crews, 


e Simulation of communications: on the basis of existing model in range, addition of the 
intervisibility aspect and of the electromagnetic propagation, 


e MMI: Taking into account of new needs (aggregation, ...). 
5.2 C4I-Simulation Interoperability 


In addition to the above-mentioned new functionalities, the SIR-Simulation interoperability topic will be 
improved on two axes: 


e Improvement of connection, 
e Introduction of SIR to JANUS connection. 
5.2.1 JANUS to SIR improvement 


As the existing linkage between JANUS and SIR was a success during the exercises, the operational 
lessons learnt led to precise specifications. These are, more particularly: 


e Management of the federation time: the use of a time protocol should be considered to facilitate the 
overall federation time control by the DISTAFF, 
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e Implementation of new messages with, for example, new SICAT and/or XL messages, or the 
automatic generation of certain messages (PTSITU or CRPOSXL). 


5.2.2 Introduction of Command Agents 
Two kinds of Command Agents will de developed for ESTHER G1V2: 


e Introduction of an ACE (ESTHER Command Agent) to simulate neighbours environment, with the 
purpose of decreasing the amount of personal required to perform this task. SIR messages will drive 
the JANUS Units representing neighbours environment, 


e Introduction of an ACE for an automatic generation of messages after a request for information 
(Location, Logistic), with the purpose of simulating the SIT. 


6.0 CONCLUSION 


ESTHER is a R&T program contributing to propose C4J-Simulation interoperability solutions for current 
education courses and training exercises with special interest on JANUS and SIR. ESTHER addresses the 
interoperability between SIR and JANUS according to a two-stage approached. First the static 
interoperability which deals with the configuration of the two systems before execution, and second the 
dynamic interoperability, which deals with the bi-directional connection during the C4I and simulation 
systems running and with their co-ordination, during run time. 


Under the umbrella of ESTHER G1V1, the connection from JANUS towards SIR was thoroughly 
addressed: The conditions of the interoperability were met with the identification and sharing of the 
needed data between both systems (static interoperability) and the most significant SICAT operational 
messages were built from the HLA simulation flow data (dynamic interoperability). Following successful 
experiments, the Army asked for ESTHER participation in the Infantry DEFTEMP exercise, whose 
operational range was tenfold increased by this realistic stimulation of the trainees via their SIR. 


This very rich operational experience on the Captains’ training will be used to improve the capabilities of 
the next ESTHER version, more particularly from the SIR-Simulation coupling point of view. For the next 
version, ESTHER G1V2, the JANUS to SIR connection will evolve, by taking into account new 
operational messages. Besides, the SIR to JANUS connection will be addressed as detailed below: 


e Taking automatically into account the messages of requests for location/status reports from the 
Company to the Squads (position, manning, resources, ...), 


e Taking automatically into account of the neighbours environment by a Command A gent. 


As for the previous version, experiments and a real Army exercise will provide and enrich the lessons 
learnt. 
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Abstract 


Modeling and Simulation at the Slovak Armed Forces has been since earlier 90's utilized to 
improve training, develop doctrine, tactics and materials, and improve combined and joint coordination. 
Recently the question of linking existing and future C3I systems with the Simulation Federation has 
emerged and is being reflected. The ability to develop a versatile modeling and simulation system in 
Slovakia linked with Air Force C3I ATC system, that can evolve with standards and tools is a big 
challenge. 

An approach has recently been identified to meet this challenge through modular, open- 
architecture Training and Simulation Centers (TSC). The TSC provide a robust combined arms 
environment where tactics, equipment, and training development can be addressed. The TSC is capable of 
brigade, air wing and below level CAX exercises, and include pre-loaded scenarios with real world 
databases. The TSC are being enhanced through the addition of Virtual Full Mission Simulators training 
facilities, Digital Communications emulators, and with the links to the Air Force (31 system standard 
called "LETVIS", which is an important element of the Slovak C3I ASOC system. This interoperable vital 
concept was and is being successfully implemented at the Air Force Academy and appropriate C3I posts 
in Slovakia 

The functional link and consistent communication standard between TSC and (31 system provides 
Slovak Armed Forces with the capability to train commanders, staff personnel, pilots, tank crew and 
cadets on developing tactics and standard procedures. Each configuration of CAX using (31 link 
feedback information has simulation tools, equipment, and capability for planning and executing 
operations interoperable with other DIS/HLA simulation and C3I nodes and operational facilities. This 
concept provides an expandable and flexible simulation, command and control environment suitable for 
training and the development of tactics and equipment, which significantly supports the process of 
Slovakia integration to NATO. 


Current Capabilities 
The Armed forces of the Slovak Republic (OSSR) currently have Modeling and Simulation 


capabilities and C3I Air Force ATC Systems capabilities at different locations. All these locations are 
very fast becoming very modern CAX platform training and exercise centers in the Central Europe. 
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The Air Force Academy located at Kosice (location of Training and Simulation Center (TSC)) 
provides a high — level general science and military academic program to all branches of the OSSR. As 
part of the instruction here, there are virtual simulators of Slovak Air Force operated light combat aircrafts 
used for individual pilot training, dog fighting training and flight training 

The Military Academy at Liptovsky Mikulas (location of Training and Simulation Center (TSC)) 
provides a high — level general science and military academic program to all branches of the OSSR. As 
part of the instruction here, there are virtual simulators used for heavy vehicle driver training, and Anti- 
Aircraft ( AA) gun training. 

Another simulation is in a classroom where a large 3-D table — top terrain simulation board with 
approximately 1/48 - scale model tanks is used for maneuver training. Students radio C2 directions for 
these tanks, using R —123 and R — 173 radios, to an operator who moves the model tanks as directed. 

Linked with above described training systems into the Simulation Federation is the C3I Air Force 
ATC system is called LETVIS. This system is a PC-based system consisting of several software 
applications that are used to monitor and evaluate the Slovak airspace situation. It provides air situation 
data display, radar data processing, and flight data processing. It exchanges information via a LAN and a 
special-purpose leased WAN. 

Additional C3I Air Force system, going to be linked is Air Sovereignty Operations Center 
(ASOC). The ASOC provides the capability to support airspace monitoring and command and control 
over mission execution ofair operations. It is a Sun Solaris-based system. Its initial capability allows the 
development and exchange of a national Recognized Air Picture (RAP). It currendy receives air situation 
and flight plan data from LETVIS system or in simulation mode generated data. It is intended to be used 
to conununicate with other ASOCs in the region, in accordance with bilateral/multilateral agreements. 

The Slovak MoD supported in the year 2000 a Letter of Request (LOR) to US Army Simulation 
Training and Instrumentation Command ( PEO STRI ) for the Modular Semi — Automatic Forces ( 
ModSAF ) Brigade and Battalion level simulation. This training and exercise simulation creates and 
controls virtual battlespace entities that move, shoot, communicate, and react without excessive operator 
intervention. 

ModSAF (now update OneSAF) is be hosted and operated on Linux machines by the Air Force 
Academy and Military Academy in Kosice and Liptovsky Mikulas. A training audience at the collocated 
Training and Simulation Centers, which trains and teaches military tactics and doctrine, and use the 
simulation for training at the Battalion and Brigade Commander and staff officer level and for use in 
training cadets at the Squadron and Wing operations level. 


(ΘΙ Systems and CAX Platform 


NATO nations are required to support a wide range of cooperative functions including combined 
training. Because it provides a cost-effective supplement to conventional training, CAX is gaining strong 
acceptance in NATO. While of growing importance, this requirement is in some background information 
is presented. 

In 1992, SHAPE established an operational requirement for a NATO CAX capability. NATO 
clearly recognized the value of CAX in an environment of constrained funding, reductions in military 
force levels throughout NATO nations and environmental impact and resulting pressures from live 
exercises. A major tenet of NATO training is that CAX does not totally replace the need for live exercises, 
but does enable a reduction in the number and scope of exercises involving the deployment of troops. The 
value of CAX is particularly important in training senior level commanders and their staffs in executing 
complex operational orders involving multi-national force elements. 

Although the requirement for aNATO CAX capability was established in 1992, the 
implementation of a NATO-owned CAX capability has been a slow and difficult process. Initially, NATO 
made use of simulation and modeling capabilities in the U. S. Warrior Preparation Center ( WPC ) at 
Ramstein Air Force Base in Germany. At present, both the WPC and the NC3A in The Hague, NL execute 
CAX programs. 
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NATO's CAX capabilities are evolving and will continue to do so for several years. At the top 
command level, a candidate model is the U.S. Joint Theater Level Simulation (JTLS) model. This model 
is the one executed by both the WPC and the NC3A for NATO training purposes. There are also other 
models in use, including a Swedish theater level model used at the PfP Simulation Center. 

For future CAX capabilities, SHAPE has formed a Multi-National Working Group which is 
formulating plans for a CAX program oriented toward the NATO Combined Joint Task Force concept in a 
multi-national environment. 

NATO requires nations including Slovakia to have some initial capability to participate in training 
exercises. The primary focus of computer-assisted exercises will be on the conduct of operations and on 
the logistics support for national forces involved in such operations. Within those guidelines, however, 
nations may choose to implement whatever simulation models are appropriate to aid in meeting national 
training requirements. At some point in the future, it will become desirable or necessary to conduct 
computer-assisted simulations on a distributed basis, with several nations and NATO participating jointly. 
In preparation for such joint CAX activity, it is recommended that nations use models that are either 
identical to or substantially the same as those used by NATO. It is assumed that for such purposes, NATO 
will provide simulation models supporting training for multi-national coalition operations to all nations 
required to participate in NATO coalition computer-assisted exercises. 

A requirement for conducting distributed simulations is the ability to exchange information 
between different models or between identical models executing at different locations. To enable this 
exchange of information, several nations in the SHAPE Multi-National Working Group mentioned above 
have been connecting several national simulations, which are currently integrated using the Aggregate 
Level Simulation Protocol (ALSP). ALSP includes a standardized structure for representing military force 
elements (e.g., tanks, aircraft, etc.) and for describing their operating parameters. The use of ALSP enables 
a specific simulation scenario (forces, equipment, fuel, logistics supplies, etc.) to be transferred between 
similar simulation models. In this manner, portions of an operational situation may be conducted by one 
participant (e.g., nation) in a distributed simulation and the results transferred to a different participant for 
other portions to be conducted. Results from the national distributed simulation experiments indicate that 
ALSP is useful but that the newer simulation integration standard called the High Level Architecture or 
HLA would be more effective. NATO has adopted HLA as the standard interface between new 
simulations, and plans for use of HLA are being developed in the Working Group. 

Future requirements can be anticipated for interfacing a national CAX host computer with NATO 
CAX systems executing on CCIS servers. At present interoperability between national and NATO CCIS 
systems will require remote NATO CCIS terminals in national HQ locations. NATO presently requires 
isolation of NATO CCIS terminals from national CCIS computer terminals by "air-gap" interfaces. 
Eventually, security Guards, developed and approved for specific applications, will enable national and 
NATO CCIS systems to be physically interconnected. Once satisfactory Guard devices are available and 
implemented, it may be possible to interface CAX models with national and NATO CCIS systems. 


The major operational functions supported by CAX are: 
Air operations and training 
Land operations and training 


Movement planning and coordination 
The system components of Slovakia/NATO CAX interconnection are illustrated in Figure 1. The 


interconnection will be similar for Slovakia participation in a NATO-hosted CAX or NATO participation 
in a Slovakia-hosted national CAX. 
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Figure 1. CAX: System Components-Near Term 


After Slovak membership in the year 2004, it is likely that NATO would extend the NATO IP 
router into Slovakia and install capabilities for Slovakia to support classified email exchanges with NATO 
subscribers. Provision of an ACE ACCIS terminal would give Slovakia an initial connectivity with NATO 
CAX information. 

It is expected that Slovakia operates its own CAX capability separately from NATO using an air 
gap interface. This is NATO Level 3 interconnection between systems. 

In the far term, it would be possible to migrate to a configuration where a Slovak CAX system 
could be connected to NATO systems through an approved Guard to achieve NATO Level 4 
interconnection, as shown in Figure 2. 
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Figure 2. CAX: System Components-Far Term 
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Simulation Federation and Pre-NATO Accession 


In the period before NATO accession, Slovakia already have developed its capability to engage in 
internal (domestic) CAX. The first step in this was to acquire or develop the necessary hardware and 
software. Computer models are in accordance with NATO standards wherever possible. Slovakia 
requested releasable interface standards through US FMS program and coordination cell. The initial goal 
was providing this training capability to the Slovak restructured Armed Forces earmarked for participation 
in NATO activities. Interfaces into domestic C3I systems drive design considerations. 

The OS SR is currently reviewing the use of both C3I systems LETVIS and the ASOC; there may 
be possible cost savings if only one system used. However, there are more than 300 LETVIS workstations 
located throughout the OS SR. LETVIS will also be used as hackup for the civil ATC system and training 
within Simulation Federation. LETVIS processes radar data, tracks, flight plans, and wealher information 
in reality or for training purpose fictive, simulated inputs and it transmits tracks and flight plans to the 
ASOC. 

The ASOC is located at the Combat Command Center. It is currently used only for training and 

testing. There are plans to transition to an eight-hour/day operation if additional positions can be funded in 
the new year. The ASOC provides the capability to process radar data, tracks and flight plans. The OS SR 
plants lo use the ASOC for exchange of information with regional ASOCs (in accordance with bilateral 
and/or multilateral agreements). The ASOC has also a link capability. 
Given the LETVIS system current widespread deployment and capability, the OS SR will continue to use 
LETVIS as the primary air surveillance system. The ASOC will be retained and maintained for 
information-sharing with regional ASOCs/NATO systems. By doing so, the technical capabilily is 
retained to exchange information with similar systems once the necessary political agreements are 
arranged. In order to fully support future information sharing with neighboring countries, the OS SR 
should operate the link between the ASOC and LETVIS as a two-way link. An added benefit is that the 
ASOC has western-style air defense C3] attributes that can be used for training in simulated environment 
for coalition deployments. 

OSSR also participates in the SHAPE/NATO C3 Agency "Cooperative Automation" and other 
seminars to familiarize PfP nations with CAX capabilities. Additionally, OSSR participate in PfP 
Simulation Network (PSN) exercises. The PfP training center in Sweden will host a distributed war 
gaming exercise facility. These exercises are expected to be open to participation by both NATO members 
and PfP nations including Slovakia. 

In order to execute NATO and national simulation models, nations are required to provide 
adequate computer facilities. Specific requirements for computer systems are coordinated with SHAPE. 
However, in general, high end Pentium PCs and/or HP with extensive RAM and hard drive capacities are 
in operation. It may be necessary to use UNIX machines in some cases. 


Post-NATO Accession 


After NATO accession, Slovakia also will need capability to participate in NATO war gaming 
exercises for units down to the brigade level. Initially, this capability will consist of a remote terminal to 
provide an extension of the NATO CCIS system (ACE/ACCIS). This will represent a level 3 (air gap) 
interconnection with NATO systems. At some point in the far term, an interface between NATO and 
Slovak systems may be implemented as security permits. 

In today's world of decreasing sizes of military forces, countries are relying on information as a 
significant force multiplier. Key to this concept is the use of automated systems to process and exchange 
information. As discussed above, the OS SR has few C3 Information systems currently in operation, 
particularly systems that support the automatic exchange of information. The OS SR is planning to 
develop new C3 information systems and to integrate them with existing training simulation tools in a 
Global Information System (GLOBIS) architecture. The GLOBIS architecture will incorporate and 
interconnect information systems from many areas within the OSSR. 
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Slovakia will also continue to implement, through acquisition or internal development, the 
capability to participate in distributed, NATO-led Computer Assisted Exercises. The initial capability 
should be designed to support internal requirements. This means that concentration will be given to 
providing interfaces to internal (domestic) systems. In addition to the obvious benefits derived from any 
training capability, this will provide Slovak officers the classroom for developing experience with CAX 
techniques. 

Slovakia was provided with tactical level of CAX training model as ModSAF (OTB) but is this 
period should obtain an operational level command CAX training model as Joint Theater Level Simulation 
(JTLS), WarSIM, JSIM or NASM models. 

The following requirements checklist will assist the OSSR in evaluating its Simulation Federation 
development program. 


Φ Has the nation requested CAX software and training from NATO? 


Φ Has the nation participated in, or is the nation prepared to participate in, the Cooperative 
Automation seminars given annually by SHAPE/NC3A? 


Φ Does the nation currently use some form of simulation model to provide CAX training for national 
command and logistics operations? 


Φ Are the nation's contributed forces equipped with suitable computer systems for the purpose of 
executing distributed CAX simulation models on national and NATO CIS systems and 
exchanging results in a near real-time mode? 


Promising vision 


In conclusion, only very efficient professional Slovak Armed Forces and stabile democratic 
political environment create the best platform for establishment of the Simulation Federation within 
integration of now existing or in future considered (31 ATC Systems in the frame of NATO membership 
under real promising vision to become a valid, credible NATO partner and member. 
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SUMMARY 


Joint Theater Level Simulation (JTLS) [6-12] is the constructive simulation used to support 
joint/combined exercises at operational and higher levels in Turkish Armed Forces. However, JTLS does 
not fit all the requirements in these exercises. The tactical considerations may sometimes have a major 
impact on the decisions at higher levels. Especially, the resolution of terrain data does not allow 
simulating the required tactical details in JTLS. Moreover, participants of an exercise should interact with 
a simulation by using either real or realistic C2 systems. The standard user interfaces of JTLS, namely 
GIAC [1-5], MPP and IMT, cannot emulate these C2 systems in most of the cases. During the game, all 
the participants that use standard JTLS interfaces have the same perception of the operational picture if 
they are at the same side. This is not very realistic. JTLS cannot provide multiple perceptions for the same 
side. HOGAY is a generic graphical interface and filtering system developed to minimize these 
weaknesses of JTLS. In this paper we introduce the architecture of HOGAY, and the method to propagate 
data in HOGAY. 


1.0 INTRODUCTION 


Unless the constructive simulations are supported by appropriate user interfaces, they cannot fulfill the 
basic requirements, e.g., better immersion, being realistic, etc., of a computer aided exercise (CAX). If a 
realistic perception of the common operational picture cannot be provided to the users based on their side, 
level in the command hierarchy, communications tools and environment, the users cannot be satisfied 
even if the most complex and realistic combat models are used to calculate the attrition and mobility of 
units. Therefore, user interfaces are at least as important as combat models in military constructive 
simulations. 


Joint theater level simulation (JTLS) has some shortcomings in this respect. In JTLS every terminal that 
belongs to the same side has the same view for the common operational picture. Every terminal of the 
same side learns about a unit as soon as any sensor of that side detects it. When the detection is fused, all 
the details related to the detected unit become available for the detecting side. This can make unrealistic 
impacts on the results of an exercise. A submarine commander can engage a surface ship more than 100 
km away as soon as it is detected by a patrol boat, which does not have any link system. The graphical 
wargame interface application introduced, HOGAY, has been developed to overcome these difficulties 
caused by the user interfaces used in JTLS. 


There are four factors affecting the design of HOGAY: 


i) Requests of users: Players prefer to interact with JTLS using GUIs (Graphical User Interfaces) similar to 
real C2 systems. Requirements may change depending on the service that the player belongs to. 
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ii) Interaction with JTLS by using a single program: Currently, the player interact with JTLS by using four 
programs, namely GIAC (Graphical Interface Aggregate Control), MPP (Message Processor Program), 
IMT (Information Management Tool), and OPM (Online Player Manuel). The interface program 
developed will perform the functions of all these programs. 


11) Visualization of detection/fusion information with a propagation delay: Currently, detection/fusion 
information is obtained instantly by all the players of the detecting side. However, this information should 
propagate with respect to the delay parameters between unit pairs. Moreover, it should also be possible to 
form links among some units. Information obtained by a linked unit is immediately passed to the other 
units under the same link without considering physical distance among them. 


iv) A list of utilities prepared by the users of the other interfaces is also taken into consideration. 


The paper is organized as follows: In Section 2, the system architecture of HOGAY is explained. Section 3 
introduces Model Client Interface, and basic processes implemented. Propagation of information and 
filtering is detailed in Section 4. Section 5 introduces Player and Controller Interfaces. Finally, Section 6 
concludes the paper. 


2.0 GENERAL ARCHITECTURE OF HOGAY 


There are three basic units forming HOGAY, namely Player Interface (PI), Controller Interface (CD), and 
Model-Client Interface (MCI). There is a dedicated MCI for the players of each side. These are names as 
MCI-PI-violet, MCI-PI-orange, etc. Moreover, there is an MCI for the controllers called MCI-CI. Players 
use PIs to interact with JTLS. CI is a PI with some privileges. It can fetch data for all sides and send some 
special administrative orders to JTLS and MCI. MCI is an interface between JTLS and end-users (players 
and the controller). PIs and CIs work on the Windows environment. They are developed by using Visual 
C++ and Delphi. MCI is implemented on Unix by using the C programming language. 


Figure 1: System Architecture 
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HOGAY has two more components also developed in UNIX environment by using the C programming 
language: GENIS-COM and MPP-COM. These components are included in the system design to improve 
the interoperability and reusability of HOGAY. MCI, PI and CI are independent from JTLS and other 
military simulation systems. These components use an application layer protocol designed for HOGAY to 
communicate. GENIS-COM and MPP-COM also use the same protocol to communicate with MCI and/or 
CIs and PIs. On the other hand, GENIS-COM and MPP-COM uses standard GENIS libraries to pass 
messages to or from GENIS. Therefore, adapting HOGAY to the version changes in JTLS is only limited 
to modifying GENIS-COM and MPP-COM which are also HLA compliant. 


3.0 MODEL CLIENT INTERFACE (MCI) 


ΜΟΙ is a parallel processing program responsible from transmitting the GENIS data to PI-CI modules and 
the PI-CI orders to GENIS. There is a dedicated MCI for the players of each side. The MCI of a given side 
downloads the data specific to its side. MC/-CI downloads data for all sides and presents this data without 
any delay. MCI-CI also modifies the delay information related to the propagation of information among 
units based on the orders given by the controllers. 


The MCI software consists of three fundamental processes and two supplementary processes for each new 
client connection, as shown in Figure 2. The fundamental processes are the Main, Genis Comm Reader 
and Updater processes. Main does the elementary operations and initiates the required processes for each 
new client connection. Genis_Comm Reader is the process responsible of listening the GENIS socket and 
storing the incoming data. Updater updates the MCI data to be send to PI/CI modules. Main creates two 
new processes PI reader and PI writer for each new client connection. PI reader receives the orders 
coming from the interface modules PI/CI and sends them to OVT. PI_writer sends the MCI data to the 
related interface module. 


geniscomm 
reader 


MCI Main 


Process 


cat, te awe a 


shared 
memory 


PI_MCI 


Figure 2: MCI Process Architecture 
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4.0 PROPAGATION OF INFORMATION 


One of the most important contributions of HOGAY is the filtering module implemented in MCI and PIs. 
To pace with the changes in the game, its implementation is distributed between these two modules. Here 
a sample scenario, shown in Figure 3, is given to describe the filtering operation. In this sample scenario 
there are three players named O1, O2 and O3. Players are thought of as virtual units with zero delay values 
to the units under their authority. In this scenario, ΟἹ and ΟΣ have two units under their command and O03 
has one unit under his command. Units are named B1 to B5.Delays between units are defined as GXY. 
(Here X and Y represent unit indexes.) For example delay between B1 and B3 is defined as G13.There are 
two relationships: 


¢ Player-Unit Relationship 
¢ Unit-Unit Relationship 


A player can have more than a single unit under his/her control. For example player O1 controls units B1 
and B2. Detections that reach to these units or the detections made by these units should be visible without 
any delay in the PI of Ol. On the other hand, the other units can learn the detections made by units after a 
delay based on some parameters such as the position of units in the command hierarchy, the 
communications capabilities, jamming, links, and the distance between units. Delays between units are 
kept in a dynamic database. Delay values can be changed by the controller during the game. 


Figure 3: Sample Scenario 


When ΜΟΙ is run for the first time, or when the unit-to-unit or player-to-unit relations are changed, the 
shortest delay path between the units and players are calculated by using Floyd’s all pair shortest path 
algorithm, and the results are kept in a matrix called Floyd-Matrix. Since Floyd’s algorithm is a time 
consuming one, O(N’), it is assumed that the matrix is symmetrical, ic. GXY is equal to GYX. When a PI 
connects to an MCI, the row related to the player of the PI from Floyd-Matrix is downloaded to the PI. 
This delay information, which gives the delay between any unit in the simulation and the player, is 
updated every time when the related row in the delay matrix in MCI is modified. 


Pls do not reflect every update to the player as soon as they receive it from ΜΟΙ. First they determine how 


long does it take to convey this update to the player based on the delay values. PI finds out the source unit 
of the update. If it is an update about a friend unit, that friendly unit is the source. However, when this is a 
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detection data, or an update about an enemy unit, PI needs to find the detecting unit. In HOGAY this is 
done by checking the location of the detected data against the ranges of open sensors available in the 
friend forces. The closest owner unit of one of these sensors that can make the detection is accepted as the 
source unit. After this point it is only a lookup in the delay relations data, which is determined by related 
row of Floyd-matrix to find out the required delay for the update in the operational picture of the unit. The 
updates are inserted into a linked list based on their update time determined by using these delays, and 
made available to the player as their time come. 


Filtering can also be bypassed, 1.6. when an information update of a friend or enemy unit has arrived, it is 
shown on the player’s screen directly without any delay. 


5.0 PLAYER/CONTROLLER INTERFACE 


PI is the interface unit that displays the propagated simulation data downloaded from MCI via TCP/IP. PI 
is the integrated form of GIAC, IMT, MPP, OPM. It includes all the options of these programs and more. 
Architecture of PI is composed of four DLLs and the main graphical interface program, as in Figure 4. 


PI 


GDataATL 
CustomSy mols 


CustomRenderer 


MPPATL 


Figure 4: Architecture of Player Interface 


GDataATL is a COM DLL implemented by using Visual C++. This module connects to MCI to download 
the simulation data and stores the updated version of simulation data. The filtered data is fired to graphical 
interface when triggered with time packets. Communication architecture of GDataATL is given in Figure 
5; 


parameters parameters 
and orders and orders 
gdata and filtered gdata 


answers and answers 


Figure 5: Communication Architecture of GDataATL 
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MPPATL is also a COM DLL implemented by using Visual C++. MPPATL connects to MPP-COM and 
fires the incoming messages to the graphical interface. CustomSymbols is a COM DLL designed for 
drawing the unit symbols in the graphical interface. This module is also implemented by using Visual 
C++. CustomRenderer is also a COM DLL implemented by using Visual Basic. CustomRenderer is used 
to draw user and unit lines, save or load them in layers. 


Graphical Interface is the basic interface developed in Delphi. In Figure 6, PI and GIAC screens are 
shown. At the first glance, both of them are quite similar. The main difference is that PI uses raster maps 
while GIAC uses hexagonal maps. Apart from this, all the information panes, buttons, and windows are 
collocated in a dockable window in PI. This window can be dragged into any place, resized or minimized 
as needed. The order menus and the other menus are also positioned as in a standard windows application. 
Hence, it is easier to train the operators which are used to working in MS Windows environment. 


PI has all of the utilities available in GIAC e.g., unit and user lines, display options, filtering options, 
panning, zooming, etc. Apart from them, it has some additional tools designed based on the lesson learned 
from the previous exercises. For example, three C2 systems, namely ICC, STACOS and a new C2 system, 
are implemented in PI. User selects one of them, and the screen looks like the screen of the selected C2 
system. This does not change the tool bar or the menu but only the operational picture is shown in a screen 
that looks like the screen of the selected C2 system. Another important new tool is Local Tracks which are 
virtual units created by players to demonstrate probable units at that location. Local tracks can be created, 
deleted, moved or shared with other players. This new utility will be very useful in the detection/fusion 
steps or in electronic war models. 


ΚΑΜΜΉΖΟΟΥ 


ΚΑΜΌΒΣΜδδ, AKMINGINT 


Please pick closer to the center of the unit. 


Figure 6: Pl and GIAC Screens 


The navigation on the map is also easier in PI where the location of the current screen in overall theatre is 
also shown in a navigation window. It is also possible to find out the length of a river or road as shown in 
the dockable information window in Figure 7. Another important tool available in PI is a very realistic 
three-dimensional (3D) flight simulator. Some screens from this real time flight simulator are shown in 
Figure 8. These screens are generated by using standard DTED formatted digital maps, satellite pictures 
and some additional data related to terrain features and textures. 
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Figure 7: PI Utilities 
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Figure 8: The Screens from the 3D Flight Simulator of PI 


PI also presents a window where the information about the units and other assets in the theatre in tabular 
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form. This tool, which is an enhanced version of IMT used in standard JTLS configuration. Another tool is 
the equivalent of MPP in JTLS where the users can see the messages generated by JTLS for them. Users 
send their orders to JTLS also by using templates similar to the ones in JTLS. With all of these utilities 
HOGAY will become the standard user interface for the constructive simulation systems used in Turkish 
Armed Forces. 


CI and PI are the same programs. During the authentication stage order menus are dynamically created 
according to the user’s type. So the only visual difference is the orders they can give. CI is connected to 
MCI-CI to get the whole simulation data without filtering in GDataATL if the user is logged as a 
controller. 


6.0 CONCLUSIONS 


HOGAY is an interface system which can connect to JTLS, and provide users with filtered perceptions 
based on command hierarchy and propagation delay. Available C2 systems in the Turkish Armed Forces 
are also emulated in HOGAY. Hence, exercise participants are better immersed into situation, and more 
realistic joint exercises can be conducted. HOGAY has also many new utilities which makes the players 
learn how to use it easier and operate it more effective. It was first used in a major exercise in 2003. 
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SUMMARY 


The concept of a future Modelling and Simulation Network is based on a methodology of knowledge and 
information management. In the framework of this methodology the Integrated Army M&S Data Network 
will be established as an operational and technical concept to allow knowledge transfer between 
operational headquarters, study facilities, procurement agencies and training installations. 

The Concept of the Integrated Army M&S Data Network has the following objectives: 


°« Efficient data acquisition, processing and administration for a Modelling and Simulation 
environment, 


¢ Data exchange between simulation systems and possible data sources (other simulation systems, C4I- 
systems, databases, etc.) based on a common information language, 


¢ Installation of a common data management process to define, establish and administer a common 
information language 


The represented results reflect a series of substantial studies conducted by civil contractors. Special 
thanks go to Dr. Stefan Krusche, Mr. Peter Arwanitis and Mr. Ralf Pfrogner, IABG GmbH, Munich for 
their outstanding work on this subject. 


1 MODELLING AND SIMULATION INFORMATION DOMAIN 


1.1 Situation 

Modelling and Simulation (M&S) is the generic term for operations research methods, the application of 
simulation in training and exercises as well as the simulation technology. M&S includes the provision and 
use of methods, models, scenarios and data in the areas of 

* analysis and planning 

* training and exercises 

* research, technology and acquisition as well as 

* support to military operations. 


The goals, based on the conceptual Army Guidelines, are: 
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* optimisation and comprehensive development approach over the application areas, 

* linkage with the Army IT System, especially with the functional and command and control systems, 

* modular driven architecture in the framework of an integrated system of models and methods, 

*  in-time provision of the best available and usable data. 

One of the unconditional key aspects of the Concept of the Integrated System of Systems M&S is the 


realisation of a corporated Information Management. 


Nowadays the existing legacy systems are tailored to the requirements of the relevant application domains. 
Systems developers use their own individual concept of information representation. Often these 
information concepts are inadequately documented, hidden in the program code or in the graphic user 
interface. Therefore the customisation and integration of legacy systems in a system of systems is either 
technically impossible, economically not acceptable or at a semantic and pragmatic level faulty. 


The Integrated Army Modelling and Simulation Data Network defines a technical framework for the 
integration of OR-systems, modules and methods in a M&S system of systems based on information 
management principles. 


The information management process in an M&S network has its peculiarities and three domains of 
support can be identified: 

* Method development, 

¢ System / Module interoperability and 


¢ Comprehensive Information Provision. 


1.2 Modelling Process 

All phases of the modelling process require support by a multi - functional information network. 

The System Analysis Phase is based on knowledge about the “real world”. Agreed concepts, doctrines and 
experience based knowledge (e.g. Lessons Learned, Case Studies, Best Practise) are the baseline for a 
conceptual model. In the next phase the conceptual model has to be formalised by using generic modelling 
methods. The formal model defines parameters and their relations. Often these parameters require 


processed information based on field tests, results of high resolution models, method requirement 
(Lancaster-coefficient, Killer-Victim-tables, Meantime failure by time) 


Particularly for the integration in a standardised M&S framework the new model has to be harmonised 
with the procedural, methodical and technical guidelines of the system framework and its components. 


The requirements for a “Developers Information Network” are 


* access to all standardised conceptual, formal and technical products and related documentation; 
* access to unstructured information (e.g. doctrines, concepts, study reports); 


¢ information collection and processing with respect to the model parameters and the problem 
definition; 


¢ predefined model documentation guidelines incorporating the complete modelling process (incl. 
assumptions and restraints, information concepts, information requirements, stability, interpretation, 
validation). 
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1.3 System Interoperability 


From the analytical perspective problem oriented individual solutions are more appropriate then 
standardised methods with a wide operative range. However it might be necessary to split complex models 
into interoperable micro-systems or modules. Also the integration of standardised common application 
services like scenario generators, terrain visualisation, data bases and evaluation tools requires 
interoperability guidelines. 


In order to classify Interoperability, the ISC has included in their NATO Policy for C3 Interoperability 
(PO(2000)39), four degrees of interoperability as follows: 


* Degree 1: Unstructured Data Exchange. Involves the exchange of human-interpretable unstructured 
data such as the free text found in operational estimates, analyses and papers. 


* Degree 2: Structured Data Exchange. Involves the exchange of human-interpretable structured data 
intended for manual and/or automated handling, but requires manual compilation, receipt and/or 
message dispatch. 


¢ Degree 3: Seamless Sharing of Data. Involves the automated sharing of data amongst systems based 
on a common exchange model. 


* Degree 4: Seamless Sharing of Information. An extension of degree 3 to the universal interpretation of 
information through data processing based on co-operating applications. 


The realised level of interoperability depends on the use case. 

In a system of systems four levels of interoperability were identified which are a pre-condition to reach a 
certain interoperability degree. 

¢ Level 1: Technical Information Exchange (You are able to talk) 

* Level 2: Syntactic Information Exchange (You are able to talk grammatically correctly) 

* Level 3: Semantic Information Exchange (Everybody knows what you talk about) 

¢ Level 4: Pragmatic Information Exchange (You act logically on a common understanding) 


In most cases the technical levels 1 and 2 can be realised. Due to the semantic diversity of legacy systems 
in Level 3 and 4 the validity of linked systems can be challenged in most cases. 


1.4 Comprehensive Information Provision 


Within a M&S network the organisational, data and procedural view of information provision determine 
the design of a future Information Management System. Based on a modern Data Warehouse architecture 
the Information Management System 


* decouples and processes “raw information” from operative databases of external information sources 
into system specific Data Views or Marts, 


* provides processing functions like aggregation, deaggregation, filtering and statistic evaluation as well 
as plausibility and consistency checks, 


¢ reflects various information concepts of heterogeneous OR Systems and their data storage, 
¢ provides information access within a decentralised organisational structure of the M&S community. 


Information Logistic via a Data Warehouse can improve quality, integrity and consistency of the required 
information. 
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Figure 1: M&S Information Model 


2 INFORMATION MANAGEMENT 


As a result of the transition from the industrial to the information age knowledge represents an inherent 
value within an organisation. Therefore Knowledge Management focuses on an efficient provision and 
mission oriented usage of knowledge for an optimised decision support inside an organisation. Over the 
past years the concept of information-based warfare has been gaining in importance in military 
organisations. The objective of information-based warfare is to achieve a decisive military advantage by 
managing and using data in all of its forms. The following research findings arise from the implementation 
of knowledge management concepts, processes and systems in civil organisations. 


¢ Structured and organised administration of all kinds of information and their logical relations 
supported by modern information technology; 


¢ Additional information (“information about information”) about the information producing 
organisation and process; 


¢ Immediate access to knowledge inside and outside an organisation (searching, collecting and 
navigating); 


*« “Comprehensive Information Area” merging training, development and management; 
¢ Simple and fast integration of new information domains via appropriate application interfaces; 


« “Experience Management” by implementing a lessons learned process. and evaluating experiential 
information with inductive methods; 


« “Information Processing” (Aggregation, Filtering, Mining, Farming, Statistic) via analytical methods 
to support the decision making process based on user requirements. 


The scope of these basic functional and conceptual requirements can instantaneously be transferred to the 
M&S community. Therefore the justified claim for data engineering support in the analytical process 
should be broadened to an all-embracing information management concept. 
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The Integrated Army Modelling and Simulation Network Project is the first step towards a standardised 
information management in the M&S community. 


3. INTEGRATED ARMY MODELLING AND SIMULATION DATA 
NETWORK 


In 2000 the M&S Branch of the GE Army Office started the project “Integrated Army Modelling and 
Simulation Data Network”. The still ongoing activity was motivated through the omnipresent demand for 
interoperability and the time-consuming and cost-intensive process of creating data sets for OR Systems. 
The main effort is the handling of structured data in a M&S system of interoperable systems. 


One major part of the project was to proof the concepts with prototypic software and experiments. The 
objective was to use approved architectural principles, e.g. the ISO IRDS standard, and realise them with 
customised Open Source products. The technical implementation is based on the use of the eXtendend 
Markup Language (XML) and Python. XML is developed to structure, store and send information. The 
language is focus on the description of data. Python is a portable, interpreted, object-oriented 
programming language. A huge variety of usable Open Source Projects were issued by the Python 
Community. 


3.1 Phase 1: Feasibility Studies 

Phase 1 was a set of mostly independent feasibility studies initiated through the C4] and M&S community. 
Phase 1 included 

* aconceptual approach for a national data management process, 

* a proposed architecture outline of an IT-System supporting the data management process, 

* the usability of data management for M&S systems, 


¢ the assessment of the significance of the NATO C3 Data Model as a standardised and flexible data 
model for the domain of Modelling and Simulation, 


* the prototypical development of a configurable interface technique for data exchange of 
heterogeneous systems on the basis of a common data language. 

3.2 Phase 2: Integrated Army Modelling and Simulation Data Network 

Summarising the results of the feasibility studies the objectives of Phase 2 were 

* to create and document a standardised data language on the basis of NATO’s Land Command and 
Control Information Exchange Data Model (C2IEDM), 

* to formulate an interoperability concept of simulation systems on the basis of a common language, 

* to provide simulation-specific information on the basis of the common language, 


* to draft a conceptual and technical framework for an Integrated Army Modelling and Simulation Data 
Network, 


* to prove the concepts through technical experiments by using prototypic software. 


This phase was mainly carried out by civil contractors under the lead of the IABG, which were already 
involved in national interoperability and data management studies. 
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3.3. Phase 3: Proof of Concept and Evolution 


The main part of Phase 3 is the proof of concept. The M&S Branch, GE Army Office is conducting an 
operational test to define the technical, organisational and functional requirements of an Integrated Army 
Modelling and Simulation Data Network. 


In parallel an evolutionary development is being pushed towards the vision of a modular Modelling and 
Simulation Network. The Agenda of Phase 3 includes 


* the integration of Common Application Services using the developed concepts, 


* the extension of the standardised data language (information concepts “Command and Control”, 
“Finance’”), 


¢ [Π6 standardised representation of terrain and environmental data, 


* the standardised representation of methods, algorithms, their parameters and relations. 
4 ARMY CORPORATED MODELLING AND SIMULATION DATA MODEL 


4.1 Data Modelling 


M&S concepts postulate interoperability, modular architecture, reuse of components and dynamic linking. 
These conceptual demands have not been translated into action yet. To build federations of OR systems 
the required levels of interoperability standards have to be officially enforced. Level 1 (Technical 
Information Exchange) is covered through a variety of activities like the HLA Runtime Infrastructure, 
DIS, CORBA and XML. Level 2 and Level 3 interoperability (syntactical and semantic information 
exchange) requires a standardised information exchange language. The NATO Policy for C3 
Interoperability [NC3B Sub-Committee AC/322 SC/2-WP/72 (Revised) Version 4.3] calls for “seamless 
sharing of data that involves the automated sharing of data amongst systems based on a common exchange 
model.” 


Today in the M&S community the definition of information is an “art work” of every individual 
programmer. A common sense information concept of the M&S domain is not existent. Extensive efforts 
have to be undertaken to reach very limited semantic interoperability between existing legacy systems. 
Due to this fact the operational usefulness of linking legacy systems might be called into question. 
However to build future federations of network oriented systems the information domain of M&S has to 
be organised by an ontological design process. This process separates the meaning of information from the 
information content. Objects, relationships, attributes and processes are organised and documented. 


Using standardised data modelling techniques and data model schemes NATO designates the ontological 
design process as Data Management and the ontology itself as Data Model. 


The ATCCIS Project has already started to define the Land Command and Control Information Exchange 
Data Model (LC2IEDM) to serve as the common interface specification for the exchange of essential 
battlespace information. The LC2IEDM extended with a national Maritime Core Data Model was the 
baseline of the M&S data management activities. The results of the analysis of a wide range of simulation 
systems were customising or complementing the LC2IEDM. The external data representation of various 
constructive simulations, high resolution vulnerability models, three-dimensional constructive simulations 
and training simulators were harmonised and documented. The results of the initial data management 
activities were available in December 2002 and issued as Army Modelling and Simulation Corporated 
Data Model (AMSCorpDM) Vs. 1.0. Examples of appended information concepts are the “3-dimensional 
Location View”, “Ballistic View”, “Lethality and Vulnerability View”, “Supplemented Person View” 


8-6 RTO-MP-MSG-022 


Integrated Army Modelling and Simulation Data Network 


(medical description of the human body). 
The AMSCorpDM can be used as 


* source for standardised data elements inside an OR system, 


* a template for a standardised external data representation of simulation systems to support the 
integration ina M&S network or system of systems, 


* an interface specification to get legacy systems inside the network or system of systems. 


Objective is to get the standardised data elements as deep as possible inside a system. 


Proceeding in accordance with the information exchange requirements and data definitions of the 
incorporated simulation systems the “common sense” modelling process defines information concepts on 
the basis of approved field-manuals, encyclopaedias, glossaries and ontologies. As a result of the semantic 
enrichment the system oriented mutual interface specification language migrated to a universal Modelling 
and Simulation ontology. 
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Figure 2: “Common Sense” Data Management 
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Adapted from the IDEF1X format an ontology schema was developed and designated as Data 
Management Reference Data Model. IDEF1X supports the semantic constructs necessary in developing a 
conceptual schema for a relational database. A conceptual schema is a single integrated definition of the 
domain data that is unbiased toward any single application and independent of its access and physical 
storage. 


4.2 Data Management Information Resource Dictionary 


The responsiveness and flexibility of the data management process is crucial for its acceptance. For this 
purpose a flexible and adjustable architecture of an information management system was developed 


* to enable the integration in the system development process, 
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* to provide efficient documentation of existing standards to be used by system developers, 
* to support flexible processes responding to information requirements in time to prevent delays. 


The system architecture is based on the ISO Information Resource Dictionary System (IRDS) Framework. 
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Figure 3: Data Management - IRDS 


4.2.1 Layer 3 (IRD Definition Schema Level) - NATO C3 Data Model 


The NC3DM as a generic data model defines the structure of the dictionary. This data model is used as a 
container and will be physically implemented in a database management system. 


By direction of the NATO Information Systems working group the NATO C3 Data Model was created as 
a generic data structure to store an application data model or schema and the related application data in it. 
So changes to the data model are made via configuration in the NC3DM and not via software update. 


4.2.2 Layer 2 (IRD Definition Level): Data Management Reference Data Model 


The Information Resource Dictionary Schema of the Data Management Process (Data Management 
Reference Data Model) is defining the data management information stored in the Information Resource 
Dictionary. 


4.2.3 Layer 1 (IRD Level): Data Management Data 
At the IRD level the actual information of the data management process is stored as 


* application schemes of incorporated systems, 

* standardised data elements 

* AMSCorpDM 

* mediation rules between AMSCorpDM and application schemes. 


A web based Data Management Information System (DaMIS) can be automatically created with the 
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DaMIRD to support system developers and data managers with all information within the Information 
Repository. 


5 M&S DATA DOCUMENT ARCHIVE 


The results of Operations Research methods eminently depends on the accuracy, integrity and plausibility 
of the available data. The analytical process and its embedded OR systems requires specific problem 
oriented data. Today at the beginning of an analytical process data collection starts as an individual sub- 
process. Information from different data sources is manually processed into the required system specific 
format. Even for common data domains like force structure, weapon system data, vulnerability and 
weapon effectiveness data a comprehensive source is not available. 


In compliance with information management principles and data warehouse concepts a conceptual 
framework for a M&S data warehouse was defined: 


¢ Data must be available in time. Situation oriented data collection is time-consuming. The M&S Data 
Warehouse has to support a routine data collection, update and amendment process. The objective is 
to anticipate possible information requirements to minimise the expense of individual data collection 
processes. 


¢ Data must be communicable. The meaning of the data content has to be clearly defined for the use in 
analytical processes and OR methods. The available AMSCorpDM was consequently implemented as 
application schema for the M&S Data Warehouse. 


¢ Data must be relevant to the problem. OR methods require specific data views. These data views will 
be kept together. After the mediation into a standardised data view based on the schema of the 
AMSCorpDM the data view is stored as a document in the M&S Data Warehouse. The M&S Data 
Warehouse is an archive of a huge number of documents. The term M&S Data Document Archive is 
more descriptive 
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Figure 4: Dual Use - IRDS 


¢ Data must be retrievable. In the sense of information management to browse, to categorise and to 
analyse data documents meta data have to be added to the original data document before storing in the 


RTO-MP-MSG-022 8-9 


Integrated Army Modelling and Simulation Data Network caesar 


M&S Data Document Archive. 


¢ Data must be adjustable. The use of the AMSCorpDM as IRD Schema on the IRD Definition level 
allows to adjust the M&S Data Document Archive schema via the specified data management process. 


The concept of the M&S Data Document Archive leads to the decision to unify the functionality of the 
Data Management Information Resource Dictionary and the M&S Data Document Archive. Technical 
studies proved the possibility to store two ore more IRD Schemes in the NC3DM. Beside the Data 
Management Reference Data Model the Army Modelling and Simulation Corporate Data Model was 
embedded in the IRD Definition level defining the common user data at the IRD Level. 


An XML workbench allows the enrichment of user data with meta data. The term “meta data” is not used 
in the sense of the ISO IRDS Framework but data which describes data. Therefore a Meta Data Schema 
was defined. It includes semantic definitions for the data originator, status of verification, validation and 
accreditation, context and topic, reliability and accuracy. Navigation and searching in the XML document 
archive will be ensured via predefined Frequently Asked Questions provided by the Query Workbench. 
All data manipulation, data aggregation and statistical evaluation functions can be realised as a process 
oriented XML editor. 
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Figure 5: M&S Document Archive 


6 SYSTEM INTEGRATION PROCESS 


The concept of an XML-based framework for a M&S system of systems requires a minimum of pre- 
conditions. Every system which uses XML for data export and import can be integrated as federate. The 
optimum would be if federates already incorporated the standardised semantic and syntax of the 
AMSCorpDM. 


The present legacy systems are not designed to communicate in a standardised environment or do not 
possess documented and standardised Application Programming Interfaces. Therefore the individual data 
representation of an application has to be transformed into an XML structured data document via a System 
- XML Proxy. For the mediation process the individual logic data model of this system specific XML data 
document has to be documented in a template and imported as application schema into the Data 
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Management Information Resource Dictionary. The structure of the documentation template is based on 
the IDEF1X notation. 


To get a standardised data document the individual application schema of the system data document is 
mapped on the AMSCorpDM. The mapping rules are documented in a mediation template and in the 
DaMIRD. This Mediation Template will initialise the Data Mediation Function (DMF). The DMF is a 
configurable interface software which supports the data migration from a system data document into 
standardised data document. The software can be integrated into systems to provide a standardised data 
import and export functionality based on XML and the AMSCorpDM. 
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Figure 6: System Integration 


The data exchange from system A to system B can technically be realised as crosswalk from the individual 
data document (A), mediated to the standardised data document (A) in the AMSCorpDM language. 
Overlapping information concepts of standardised system data document (A) with standardised system 
data document (B) can be transformed directly, gaps and semantic differences have to be bridged by 
Application Gateways. 


Document Name Originator Format Schema 

Application Database Application Individual (ASCH, DBMS, XML...) | Individual 

System Data Document Application XML Application Schema - IDEF1X 

Standardised Data Document | Data Mediation | XML AMSCorpDM (System View) 

(System View) Function 

Meta Data Document Manual / XML | XML Meta Data Schema 

Work Bench 

Enhanced (standardised) Data | XML Work XML AMSCorpDM & Meta Data Schema 

Document Bench 

Application Schema Manual XLS-Template (IDEF 1X) Meta Data Schema (Data Management 
Reference Schema) 

Mediation Rules Manual XLS-Template (Mediation) Meta Data Schema (Data Management 
Reference Schema) 

AMSCorpDM Manual XLS-Template (Data Management) | NC3DM 
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The same methodology can be used to realise the information exchange between OR systems, C4I systems 
and other IT systems. 
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Figure 7: Data Exchange 


6.1 Multi-Role Common Platform 


The functionality of the unified M&S Data Document Archive / Data Management IRDS is tailored to 
different roles depending on the supported processes and the required information of an organisation. The 
Multi-Role Common Platform supports data management, data provision, data processing and data 
exchange. The process tailored satellites can be linked into an Army M&S Integrated Data network which 
forms an eminent component of a future M&S system of systems or M&S network. 


7 CONCLUSION 

Starting from national and international concepts and standards an operational and technical architecture 
of an Information Management System was developed. Experiments proved the feasibility and practicality 
for various simulation systems. However it is one of the preliminary steps towards a M&S system of 
systems. One major future task is to enforce the implementation of the approved standardisation activities. 

In December 2004 the GE Army Office will issue a final project report and will come forward with a 
proposal for the further way ahead. 


8 REFERENCES 


[1] Information Resource Dictionary System (IRDS) Framework, ISO 10027, International 
Organisation for Standardisation, 1990 


8-12 RTO-MP-MSG-022 


OTAN 


Integrated Army Modelling and Simulation Data Network 


[2] Krusche, Dr. Stefan - DBU M&S - Final Report, IABG, Munich, 2002 


[3] Hoffmann, Prof. Dr. HW.; Hofmann, Dr. M.; Pétzsch, V.: Standardisation of Command and 
Control Modules for the German Army - Final Report, UNIBw M StudFBer Informatik, Munich 2003 


[4] Pfrogner, Dr. Krusche: Corporate Data Model Ausbildung - Final Report, , IABG, Munich, 2002 


[5] Arwanitis, Peter; Krusche, Dr. Stefan; Pfrogner, Ralf: Corporate Data Model Infantery - Final 
Report, IABG, Munich, 2002 


[6] Krahl, Daniela; Windheuser, Ulrich; Zick, Friedrich-Karl: Data Mining, Addison - Wesley , Bonn, 
1998 


[7] Schulte, Tomas: Data Management and Data Standardisation, Conference on the Relevance of 
Data Management for Standardisation and Interoperability, Carl Cranz Gesellschaft, 2001 


[8] Sinclair, Mark R.; Tolk, Dr. Andreas: Building up a Common Data Infrastructure, 2002 


[9] Smith, Barry: Aristoteles 2002in T. Buchheim, H. Flashar, R. A. H. King (eds.): “Kann man heute 
noch etwas anfangen mit Aristoteles?”, Meiner, Hamburg: 2003, pp. 3-38. 


[10] Gates, Ray: Metadata Standards, Presentation to IRMAC Metadata SIG, Toronto, 2003 


[11] | Zimmermann, Bernd: Konzeption und Aufbau des Datenverbundes Modellbildung & Simulation 
Heer, Presentation to GE Army Office, Cologne, 2001 


[12] Federal Information Processing Standards Publication 184: Integration Definition for Information 
Modeling (IDEF1X), 1993 


[13] ISSC NATO Open Systems Working Group: ADatP-34, NATO C3 Technical Architecture 
Volume 2 Architectural Description and Models, Vs. 3.0, 2001 


[14] Army Tactical Command and Control Information System Working Group: ATCCIS Working 
Paper 3-1, Edition 5.0, Data Naming Procedures for the LC2TIEDM Data Model, BELGIUM, 2002 


RTO-MP-MSG-022 8 - 13 


Ι 
«Φ 
YW 


Ι 
5 ' Click here to view PowerPoint presentation; Press Esc to exit ' ΞΞ 
OTAN pete οὐλὰς πθμλίώσας seit Siu ει εἰεε hose AE ; Ξ 


ORGANIZATION 


INTEROPERABILITY BETWEEN THE RNLA C2 WORKSTATION AND 
THE ‘KIBOWYP CONSTRUCTIVE SIMULATION TOOL FOR 
OPERATIONAL SUPPORT AND TRAINING 


Wim Huiskamp, 
Angela Kwaijtaal, 
Stephan Fiebelkorn 


TNO Physics and Electronics Laboratory 
Command & Control and Simulation 
P.O. Box 96864, 2509 JG, The Hague, The Netherlands 
Tel +31 (0)70-3740274, Fax +31 (0)70-3740652 


Email: huiskamp@fel.tno.nl, kwaijtaal@fel.tno.nl, fiebelkorn@fel.tno.nl 


SUMMARY 


The Royal Netherlands Army (RNLA) is currently developing the C2 WorkStation (C2WS), which is a 
configurable, distributed information system that provides generic functionality to support the Command 
and Control process. One of the main tasks of the C2WS is to support the users in building and 
maintaining a Common Operational Picture (COP) that provides adequate situational awareness. TNO- 
FEL has performed experimental studies on the C2WS to investigate the issues related to interoperability 
between C2 systems and simulators. The aim is twofold : support the staff training process by using the 
C2WS as an interface between trainees and simulation tool (‘train as you fight’) and investigate the 
options for operational C2 decision support tools based on simulators. 


The RLNA performs staff training through Computer Assisted eXercises (CAX) with the ‘KIBOWI’ 
constructive simulator. Currently manned Lower-Control cells provide the interface between the 
simulation and the trainees. The vision for the future is to develop more automated interfaces between the 
simulator and the C2 systems. The simulation will provide stimuli to the C2WS (e.g. unit detection or 
displacement) and thus interact with the trainees through the operational C2 systems. Instructors can now 
also better assess the user's performance with these C2 systems. Interoperability with Decision Support 
Systems (DSS) concentrates on Course of Action (COA) analysis and mission planning. The mission plan 
is defined in the C2WS and automatically transferred to the DSS. The DSS analyses this input through 
simulation and predicted results (e.g. rendezvous times) are routed back into the C2WS as a new planning 
overlay available for evaluation by the C2 operator. 


The architectural approach to our interoperability need is to provide a software gateway between the 
C2WS communication network (based on XML messaging) and the High Level Architecture (HLA) 
standard. The link to HLA provides the possibility to connect many modern simulation components to the 
C2WS architecture. The HLA development process that was followed provides a generic approach to 
simulation interoperability for the C2WS. This process concentrates on defining a datamodel that matches 
the requirements and features of both the C2 system and the available simulation assets. 


This paper presents an overview of the possible use of interoperability between C2 systems and simulation 
systems, an overview of the architecture, the development of the demonstrator and our results to date. 


Paper presented at the MSG-022/SY-003 Conference on “C3I and M&S Interoperability”, 
held in Antalya, Turkey, 9-10 October 2003, and published in RTO-MP-MSG-022. 
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1. INTRODUCTION 


This paper addresses the approach used by TNO-FEL to develop and demonstrate concepts for 
interoperability between C2 systems and Simulations. Simulation interoperability for C2 systems enables 
applications in training of military users, operational support, procurement and assessment and evaluation 
of C2 systems. The presented project is aimed specifically at the Command & Control Workstation 
(C2WS), a new C2 information system for the Royal Netherlands Army (RNLA), which is under 
development. The requirements for the design of the C2-Simulation interoperability architecture are: 
flexibility, scalability, robustness and compliance to international standards. 


As a first demonstrator of interoperability between C2 systems and simulations, the coupling of C2WS 
and the KIBOWI wargame, an HLA (High Level Architecture) based Simulation system, was chosen. The 
demonstrator concentrates on providing improved Situational Awareness (SA) for trainees by means of the 
C2WS. 


The next section of the paper addresses the need for interoperability and the general concept of coupling 
C2 systems to Simulations. Sections 3, 4 and 5 explain the background for the C2WS, KIBOWI and HLA. 
The following sections discuss the system architecture, implementation issues and some results and 
conclusions of this project. 


2. LINKING C2 SYSTEMS TO SIMULATION MODELS 


Linking C2 systems to Simulation systems has many potential applications. Simulation systems can 
stimulate the C2 system by providing data that simulates the 'real-world'. This information will appear to 
have been received from peer C2 systems. In this way a simulated COP (Common Operational Picture) is 
created that is based on a simulation scenario. Applications of this technique are: assessment of C2 
systems (performance, user interface etc.), assessment of C2 operator capabilities or training of C2 
operators. The simulation can provide the C2 operator with operational decision support by executing 
‘what-if’ scenarios. These scenario's can support the operator in his decision making process (e.g. mission 
planning or assessment of alternative COA's). New or experimental parts for an existing C2 system can be 
evaluated before purchase or even before full development of the component by replacing an existing 
component of the C2 system with an embedded or external simulation. Simulated systems can be 
‘initialised’ from the existing COP in the C2 system and a simulation run can be started based on this 
information. The advantage of using simulations as a tool for stimulation of C2 systems, as opposed to 
‘role players', is that the simulation has a consistent, controlled and reproducible behaviour, which allows 
objective assessment of system and/or operator performance. TNO-FEL has recognised an opportunity to 
support the C2WS assessment activities and the current C2 staff training process by ongoing experimental 
studies on coupling of our simulation tools with C2 systems. The aim of the research is to develop a 
flexible and future-proof approach to the C2-Simulation interoperability problem. First we need to clarify 
what we really mean by ‘interoperability’. Interoperability is the degree to which entities are able to co- 
operate in achieving a common goal. There are many interpretations of the concept of interoperability 
between computer systems. It varies from having a network connection and being able to transfer files 
(e.g. email) to using exactly the same applications at all systems and completely sharing the information 
they process. A commonly used form of interoperability is ‘information interoperability’, because it offers 
optimal connectivity between systems, while preserving maximum independence. Information 
interoperability is defined as the ability of systems to automatically exchange and interpret information 
that is common to those systems [1]. 


In this paper we focus on information interoperability that is achieved by the automated exchange and 
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interpretation of structured information between systems. With minimum user intervention, C2 systems 
and Simulation systems must be able to automatically interchange certain information and utilise that for 
further processing. This means that the information must be structured, because this enables functionality 
such as distribution by subscription on certain topics, presentation of information and filtering by specific 
selection criteria. The emphasis here lies on the exchange of information (rather than 'free format! 
databits), preserving its meaning, integrity and context. Structured information is described formally by a 
'‘Datamodel'. The datamodel thus represents the foundation for information interoperability. In the most 
common case where many systems have to exchange information, standardisation of a common ‘interface’ 
is a key factor to achieve information interoperability. Otherwise, dedicated interfaces are needed between 
every pair of interconnected systems, leading to an exponential growth of the number of interfaces 
required [Figure 1],[8]. Preferably the exchange should not depend on proprietary products, such as 
database management systems and communication systems. 


C2 system Simulation 
| | 
| | 


SSS 


Figure 1 C2 and Simulation Interoperability (dedicated interface) 


The key notion for information interoperability is standardisation. By having common agreements on 
which information is exchanged, in what format, and under what conditions, it becomes easier to allow 
systems of different types to interoperate [Figure 2]. 


C2 system Simulation 


Figure 2 C2 and Simulation Interoperability (standard interface) 


3. COMMAND & CONTROL WORKSTATION (C2WS) 


The C2WS [Figure 3] is a configurable application platform and information system that provides generic 
functionality to support the Command and Control process. The C2WS supports the users in building and 
maintaining a COP that provides adequate Situational Awareness. The C2WS is being developed at the 
RNLA C2 Support Centre, with co-operation of TNO-FEL. The system architecture of the C2WS 
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comprises of three layers: presentation services, business services, and data services. 


The presentation services layer is responsible for gathering information from the user and presenting 
information to the user using the services of the business services layer. 


The business services layer is responsible for end-to-end business transactions such as maintaining roles, 
contexts and business objects and the logic that applies within these concepts. 


The data services layer is responsible for storage, retrieval, maintenance and integrity of data. The data 
services layer is also in charge of publishing as well as subscribing and listening to data on the C2 
network. 


The information exchange in the C2WS environment is implemented through a middleware layer named 
‘C3I Framework’. The middleware follows the RNLA C3I Architecture (C3IA) Information Model 
(C3IA-IM) for C2 applications within the RNLA [2]. The C3I Framework uses commercial of the shelf 
publish/subscribe services (Tibco Rendezvous) and a tailored information exchange language based on 
XML messaging. The C2WS has conversion modules for RNLA legacy systems such as the Integrated 
Staff Information System 'ISIS' and for the future Battlefield Management System 'BMS'. 
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Figure 3 C2WS GUI (RNLA prototype) 


At the time of writing, the C2WS supports GIS functionality for placing units and lines/areas on the map. 
The network functionality is partly implemented, for example updates of the COP for a certain 'context' 
can be exchanged between different C2WSs. However a means for a new C2WS to hook into the network 
and receive the full current COP has not yet been implemented. 


4. KIBOWI 


KIBOWI is a detailed constructive combat simulation model that takes into account manoeuvre, fire 
support, combat engineering, air defence, air support, combat service support operations and amphibious 
operations. The model is capable of simulating ground operations at battalion, brigade and division levels. 
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KIBOWI can represent entities on a platform (e.g. vehicle) and aggregate (e.g. platoon, company) level. 
KIBOWI is normally used by the RNLA as an exercise driver for Command Post Exercises (CPX). Some 
other users are Belgian brigades and the Bulgarian army. Primary training audiences are typically staffs at 
battalion, brigade, and division level. 


In the C2WS-KIBOWI federation KIBOWI drives the demonstration scenario by providing an operational 
context for the mission. The operational context simulated by KIBOWI consists of formations of own and 
hostile ground forces. These units provide a dynamic and representative environment for the C2WS 
operations. During a scenario run, each KIBOWI unit executes a predefined list of orders. This eliminates 
the need for user interaction during execution and ensures repeatability of the scenario. 


Figure 4 KIBOWI GUI 


KIBOWI simulates both aggregated and platform level entities in the scenario. Since KIBOWI is not 
capable of aggregating and de-aggregating units dynamically, care had to be taken during scenario design 
that no interactions would occur between KIBOWI aggregate units. 


An HLA compliant version of KIBOWI was developed in the context of the NATO DiMuNDS 2000 
project. Because no RTI implementation was available for the platform that the KIBOWI software runs on 
(i.e. OpenVMS on Digital AlphaStation), KIBOWI uses a gateway component to link to the HLA. 


The C2WS-KIBOWI federation adopted the DiMuNDS 2000 datamodel with only a limited number of 
modifications. Therefore, the KIBOWI HLA gateway could be adapted easily to the new federation 
(mainly the mapping functions were affected). No changes were required in the code of KIBOWI itself. 


5. HIGH LEVEL ARCHITECTURE (HLA) 


The High Level Architecture (HLA) is an architecture for reuse and interoperation of simulations [3], [4], 
[5], [Figure 5]. The HLA is based on the premise that no single simulation can satisfy the requirements of 
all uses and users. An individual simulation or set of simulations developed for one purpose can be applied 
to another application under the HLA concept of the Federation: a composable set of interacting 
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simulations. 


HLA System Architecture 


Α Saal Simulations Live 
upport too (Federates) participants 


Run-time Infrastructure (RTI) 


Figure 5 HLA Federation 


The intent of HLA is to provide a structure that will support reuse of capabilities available in different 
simulations, ultimately reducing the cost and time required to create a synthetic environment for a new 
purpose and providing developers the option of different implementations within the framework of the 
HLA. The baseline definition of the HLA includes the HLA Rules, the HLA Interface Specification 
(IFSpec), and the HLA Object Model Template (OMT). The HLA interface specification defines the 
services that HLA provides to the application. These services include Object Management 
(publish/subscribe) and Time Management (1.6. synchronisation between distributed applications). The 
Federation Object Model (FOM) is the datamodel of the HLA Federation. The OMT is the standard 
datamodel format that is used in HLA documentation. The HLA specification was adopted by the US 
Defense Modelling and Simulation Office (DMSO), by NATO and it has now been accepted as IEEE 
Standard 1516 for simulation interoperability. Development of a generic coupling between C2 systems 
and HLA thus provides the possibility to connect modern simulation components to the C2 environment. 


One of the main components of HLA is the Run-Time Infrastructure (RTI). The RTI implements the HLA 
IFSpec and allows the user to invoke the RTI services to support run-time interactions among Federates 
and to respond to requests from the RTI. This interface is implementation independent and is independent 
of the specific object models and data exchange requirements of any Federation. At TNO-FEL we 
developed an HLA based middleware layer, called the Runtime Communication Infrastructure (RCI) [6] 
which supports HLA. The RCI shields the developer from many intricate details concerning the usage of 
the HLA-RTI when developing either a Component or a Federate. The RCI includes a C++ code-generator 
to translate the required HLA-OMT descriptions into easily accessible object-oriented classes. 


6. BRIDGING THE GAP 


Previous attempts to couple C2 systems with simulations were often ad-hoc and resulted in tailor-made 
connections for every specific combination of C2 systems and simulation models (See also references in 
[8]). A new connection had to be developed for each new system that needs to be included. This approach 
means a lot of work for both the C2 system and the simulation models, [see Figure 1]. A more flexible 
approach is the use of an intermediate layer as show in [Figure 2]. 


Once a system or simulation has a (tailor made) adapter for the intermediate layer, the system can be 
connected to other systems or simulations without any additional work on the other players. 
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The approach that was followed to achieve C2WS-Simulation interoperability resembles the 'intermediate 
layer' solution, however with an important difference: both the C2WS systems and the Simulation systems 
already support interoperability within their own domain. 


The C2WS system uses the ‘C3I Framework’ middleware, which is based on Tibco/Rendezvous. The 
simulation systems use the HLA interoperability standard. We have developed a 'Tibco-HLA gateway’ to 
connect TIB/RV on one side to HLA on the other side (see Figure 6). 


In addition to interoperability at the technical level (protocols, networks etc), we also need to develop the 
information interoperability for the gateway which aligns the Datamodels and provides a two-way 
mapping for all relevant attributes. HLA federates define their data exchange via a Federation Object 
Model (FOM). The FOM has to be agreed upon between the systems that need to be connected. For the 
C2-Simulation system a C2WS-KIBOWI Federation has been designed together with an initial FOM 
based upon the FOM used previously in the NATO DiMuNDS 2000 demonstration [7]. 


C2-Sim Interoperability 


C2 Native Data-model Federation Object Model 


Figure 6 C2-Simulation Datamodel Interoperability 


This FOM describes four generic objects, which are : 


¢ Weather, 

¢ Stationary, 

¢  StationaryMultiLocation and 
* Mobile 


The information that is exchanged via the FOM consists amongst other things of the position of the object 
and depending on the object information, for example status and speed. Given the different development 
history of the C2WS and the DiMuNDS FOM it is often impossible to directly map the information 
exchanged between C2 systems onto the FOM. 


In most cases it is necessary to combine information from the C2 system in order to get it mapped onto the 


FOM and vice versa. For example, the following fields were identified for a unit message that need 
adaptation before they can be mapped on either the FOM or on the C2 information. 
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Table 1 Data mapping fields (not exhaustive) 
FOM C2WS 


ObjName Name 


A name in the FOM needed to be restricted to 10 characters, the FOM only knows of four different parties 
while the C2WS allows many more different nationalities, and the location of a unit in the UTM system of 
the C2WS needed to be translated into the relative map co-ordinates used by the FOM. Specific 
conversions and layout issues had to be resolved and implemented to realise any coupling between the two 
domains. 


The C2WS-HLA Gateway was developed for the purpose of incorporating a C2WS in the Federation. This 
Gateway (see Figure 7) was implemented using two processes, one attached to the RCI (HLA middleware) 
and the other attached to C3I Framework. Both sides use a publish/subscribe method to distribute data on 
their respective networks. The C3I Framework listens to messages on the C2 network and places an image 
of the object/interaction data concerning the C2WS entities (to which a subscription was issued by the 
Gateway) in shared memory. The RCI process subsequently reads this data from shared memory and maps 
it onto the HLA-FOM via the RCI middleware. The same holds for communicating data from the HLA 
Federation to the C2WS world where the C3I Framework publishes and updates the object/interaction data 
received from the Federates in the simulation. 


C2WS Gateway Simulation 


‘GUI’ for Staff Training Tool Staff Training Tool 


Figure 7 C2WS Federation with C2WS-HLA Gateway 


The Gateway code is currently ‘handcrafted’. Development of a Codegenerator tool that translates C2WS 
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object structures into ‘OMT? like datastructures would simplify matters. Such a tool would effectively turn 
the C2WS-HLA Gateway into an OMT-to-OMT mapping process. 


7. RESULTS 


The prototype demonstrator for the C2WS-KIBOWI federation is capable of generating a COP image on 
the C2WS based on data received from KIBOWI (‘oneway’ traffic). The gateway handles a limited set of 
units and other C2 items, which shall be extended in further versions of the demonstrator. 


Due to the early stage of the development of the C2WS, some cumbersome precautions have to be taken 
when demonstrating the simulation functionality. The COP updates on the C2WS are incremental, so only 
changes are broadcast to other C2 stations. A full COP transfer for when a new C2WS is added to the 
network, or in our case, for simulation purposes, has not yet been implemented in the current version. 


Implementing a coupling of this RNLA C2 system with a simulation component in such an early stage of 
its development has resulted in encouraging insights in the possible additional functionality required of the 
C2WS and indeed other C2 systems. 


8. CONCLUSIONS AND FURTHER WORK 


The demonstration system achieved its overall objectives and so far received positive reactions from its 
audience. Some lessons learned to date from the project are: 


¢« Use a single (authoritative) source for common data like terrain maps and data, co-ordinate 
conversion algorithms, equipment and weapon parameters, etc.; 

¢ Test and Evaluation of C2WS prototypes in a simulated environment is very cost effective; 

* Operators need to become aware that C2 WS response is not ‘real-time’; 

* Operators need to become aware that C2 WS information is not always the ‘truth’. 


* Pursue for a standardised C2-Simulation Datamodel, represented in FOM format. 


In addition to full compliance with HLA, the innovative architectural concept that was developed supports 
the key capabilities required for future C2-Simulation interoperability applications : 


¢ An abstraction layer (e.g. TNO-RCI middleware) and a code generator hiding complexities of the 
underlying simulation interoperability standards and enabling simulation protocol migration with 
minimal changes to the functional implementation. 


¢ A structured development process (the FEDEP [5]), supported by appropriate tools, enabling 
migration of legacy simulations and COTS products to the new standard architecture; 


¢ The Gateway approach as the optimal solution to allow interoperability between the different 
worlds that C2 and Simulation are today. It is unlikely that one single standard for all information 
exchange between systems is achieved in the near future, even if we restrict the ‘universe’ to 
NATO ΟΖ] systems. 


The (completion of the) design and the development of the C2WS falls outside the scope of our project. 
However, we do believe that future C2 systems will include the design requirement for interoperability 
with simulations and the results of our project will therefore influence the development direction of the 
C2WS. The C2WS is on its way to become a useful and exciting new C2 system, reaching out to the 
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useful and exiting new simulation standard HLA. 


The RNLA is planning to support staff training with the Midlife Update (MLU) of KIBOWI. This MLU is 
now being developed by TNO-FEL. The MLU will have the following additional features: 


¢« The MLU is coded in JAVA, this provides platform independence (e.g. Windows, Linux, Unix) 
and eases maintenance. 


¢ The MLU is internet based (TCP/IP). This makes remote training with an internet connection 
possible. 


¢ The MLU provides multiple modes of use; e.g. the warfighter setting ‘train as you fight’ and the 
classroom setting. 


The demonstrator will be developed into a fully operational coupling between the C2WS and the MLU of 
KIBOWI. The first application will be support for staff training. The Gateway will be extended with more 
sophisticated filters and features that allow instructor control over which entities are transferred (e.g. blue 
only) and provide additional options to delay the transfer of ‘red’ unit position updates as if these were the 
result of observations. 


Future research work will focus on the use of KIBOWI as an operational support tool for the C2 process. 
KIBOWI will evaluate and analyse COA’s prepared on the C2WS. This type of simulation based decision 
support tool provides the commander with a range of new possibilities. This next version of the 
demonstrator will require a ‘two-way’ communication between the C2WS and KIBOWI. 
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ABSTRACT 


Modelling and Simulation (M&S) is a powerful tool that is used to support training and analysis of 
military operations, development of military concepts and gradually, it is becoming an integral part of 
modern (31 systems. As the web has evolved, new ways of carrying out modelling and simulation and 
realizing C3I systems have emerged. These achievements address some of the research issues considered 
vital for future development of the M&S/C3I domain. Firstly, web related technologies provide means of 
overcoming the interoperability barriers, for example through standardized data exchange formats (such 
as XML), platform independent software (for example Java) and shared knowledge of a domain 
(semantics). Secondly, networked environments offer ways of setting up virtual organisations, sharing 
common goals and interests, to efficiently collaborate in problem solving. Finally, computer networks 
promote efficient sharing of resources, which for example could increase the reuse of existing models or 
utilize idle processing capacity of computers. 


At the Swedish Defence Research Agency (FOI) there is ongoing research, targeting the role of 
network/web based technologies in M&S, to support defence communities in their work. Our vision 
comprises an environment supporting the entire M&S-process, including conceptualization, scenario 
definition, design, development and execution. All these tasks should be maintained by a framework for 
collaboration, which lets users; developers, analysts, administrators etc, jointly work on a project. During 
the first phase of this research focus has been on efficient resource sharing and means of collaboration. 
Through experimental research and implementation of a prototype (NetSim), methods and techniques 
have been identified to form a framework for collaborative work, resource management and distributed 
execution. 


Following current trends within development of networked applications, decentralized (Peer-to-Peer) 
solutions were of primary focus when implementing the prototype. Based on the open source Peer-to-Peer 
platform JXTA, two distinct components of our envisioned system were implemented, namely; a 
decentralized resource management system deploying a network of workstation for execution of HLA 
federations and a collaborative environment for joint modelling of federations. Our results show that the 
utilization of Peer-to-Peer concepts for resource sharing and collaboration are favourable in terms of 
scalability, robustness and fault tolerance. The technology allows formation of virtual organisations 
without the need of intermediate resources like centralized and powerful servers. However, some aspects 
of our implementation temporarily rely on central control, thereby diminishing the benefits of the Peer-to- 
Peer paradigm. Future research will therefore address distributed algorithms for synchronisation of 


Paper presented at the MSG-022/SY-003 Conference on “C3I and M&S Interoperability ”’, 
held in Antalya, Turkey, 9-10 October 2003, and published in RTO-MP-MSG-022. 
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collaborative work and a more flexible and extendable approach to resource management. Furthermore, 
as many studies have pointed out before, one of the great challenges of any type of Peer-to-Peer system is 
discovery and matching of resources. This is an area that deserves great attention when planning for the 
next generation C3I/M&S tools. 


1 INTRODUCTION 


C3I systems of the future Network-Centric Defence are dependant of the network and require 
interoperability between different components of the system. During the past decades the modelling and 
simulation (M&S) community, particularly the area of distributed simulation, has explored the possibility 
of coupling live and simulated systems in joint exercises and hence addressed the interoperability issues 
from many perspectives. Therefore, many of the challenges that future C3I systems are facing have 
already been dealt with by the M&S community. 


M&sS as an integrated part of C3I systems could provide means for decision support, simulation based 
acquisition, planning, training, etc. Furthermore, M&S could be employed as a tool for development of 
C3] systems, e.g. for studies, test and verification. The mutual benefit of a close collaboration between C31 
and M&S systems has been identified and discussed during recent years [1] and the High Level 
Architecture (HLA) has been suggested as a mean to interface and increase interoperability between the 
two systems. 


The High Level Architecture (HLA) is an IEEE’ standardized architecture (HLA 1516), that provides 
means of connecting independently developed components (federates) to form simulations (federations). 
A simulation is formed by connecting individually developed components to a Run-Time Infrastructure 
(RTD, which implements the HLA standard. The RTI resembles a distributed operating system for 
simulations by providing services that enable interaction between participating components [2]. 


Integrated computer based decision support tools have also been identified as an important part of future 
C3I systems [3]. The fundamental idea is to make decisions faster and at the same time improve the 
quality of the decisions made. Tools that are accomplishing this are generally based on simulation 
systems, which often require interoperability and collaboration between different actors, such as decision- 
makers, field commanders, and technical staff etc. To realize these ideas efforts have been made within the 
area of computer based collaboration, enabling sharing of various resources, work areas, tools and 
environments. These techniques will not act as a substitute for real human-human work, but can be used 
for bridging distances and increasing and facilitating cooperation. 


An evolving technology that could provide a fundament for modern C3I systems is Peer-to-Peer (P2P) [4, 
5]. The technology offers advantages such as live peer interaction and collaboration, ad-hoc networking 
and robust and fault-tolerant systems through redundant application and communication paths. P2P- 
technologies aim at utilization of resources at the edges of Internet as opposed to the traditional client- 
server model. P2P can be seen as an alternative network architecture that doesn’t exclude, but does not 
naturally build upon centralized solutions [6]. Essentially, P2P is about community and mutual sharing of 
resources, by organizing nodes into groups sharing common interests and goals. 


The aim of this paper is to give an overview of work related to web/network based modelling and 
simulation carried out at the Department of Systems Modelling, Swedish Defence Research Agency. 
Moreover it provides an insight in ongoing research in this area and its relation with integrated M&S/C3I 
systems. 


' The Institute of Electrical and Electronics Engineers 
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2 BACKGROUND 


2.1.‘ Interoperability 


Connecting systems of various types developed for different purposes, during different technological eras 
and for different platforms, inflicts major difficulties, especially in terms of interoperability. It is required 
that systems are capable of communicating between them, but also that the communication is semantically 
and syntactically agreed upon. If these basic requirements are not met, systems may interoperate for the 
wrong reasons. The problem of interoperability is important to address in the management of highly 
distributed systems like distributed simulations and C3I systems. The issue of interoperability has been of 
major concern within the modelling and simulation community for some time now. Already during the 
80’s, efforts were made to standardize distributed simulations to facilitate interoperability among 
simulators, simulation models etc. The efforts made and experience gained in this forum, are definitely 
worth considering when planning for and developing integrated future C3I - M&S systems. Moreover, the 
rapid development of web/network related technologies brings new possibilities for overcoming the 
interoperability barriers and problems related to availability and management of resources. For example, 
through new ways of exchanging data (XML), distributing resources (P2P and Grid computing), and 
assuring semantic and syntactic correctness (Semantic Web initiative’). 


2.2. The NetSim project 


In 2001 a project was initiated at the Department of Systems Modelling, FOI, with the goals to manage 
and facilitate some of the issues concerning simulation interoperability, availability and reusability. The 
project was called WebSim, and focused on the area of web-based M&S. It produced interesting result 
regarding adapting legacy simulations to the web, and also concerning implementing HLA federations for 
web-based composition and execution. Some of the work was reported in [7]. 


As a follow-up to WebSim the NetSim project was formed. NetSim is a shortening of the full name 4 
Network Based Environment for Modelling and Simulation. The new project does not reject the ideas of 
web-based M&S, but instead extends the concept. The main directions are to investigate decentralized 
solutions for M&S in general, both web-based solutions and other possibilities. For this cause a prototype 
environment is being developed. It is intended to provide functionality and tools for the complete M&S 
life cycle, all the way from design and simulation modelling, to execution and documentation. The NetSim 
environment shall also provide access to distributed resources such as simulation models, various data, or 
even CPU usage, as aid for M&S activities. 


NetSim is intended for use within several different defence systems. It will support computer-based 
collaborative work, such as shared work areas and means of communication. This means that NetSim will 
not only work as a common platform for M&S, but also as a place of meeting for (M&S) people. In the 
computer environment, software developers, Subject Matter Experts (SMEs), soldiers and VV&A people 
may meet, and use and share each others’ resources and expertise. In modern and future defence systems 
M&S is used as technical aid for decision making, Simulation Based Acquisition (SBA), logistics 
planning and military training etc. Hence, NetSim could constitute an excellent tool for those systems and 
activities, and for activities where M&S is not currently used, but would be beneficial if made possible. 
An example of this is the support for mobile clients such as PocketPCs. This allows people on the move to 
interact with the environment. Hence a soldier may receive direct access to data and information about 
supplies and routes, and may collaboratively plan or decide what forthcoming actions to take. This also 
means that dynamic and actual data can be transmitted back to the base, and more optimized and well- 
planned decisions can be made easily. The NetSim environment will allow people (nodes) within a 
network to collaborate through their computers, which makes it easier to create a common picture of the 


' The semantic web is a web of machine-readable information [8]. 


RTO-MP-MSG-022 10-3 


NetSim — A Network Based Environment for Modelling and Simulation Pas eNte AITO 


situation/problem to handle, and supplied direct contact between all actors concerned. It hereby allows 
immediate access to the competence and expertise needed. 


2.3 The NetSim environment prototype 


At present a NetSim prototype is implemented. The prototype is not yet complete, but it demonstrates 
useful functionality and what the environment can be used for if employed in defence systems. It is 
implemented as a lightweight Java application, in which a user retrieves access to M&S tools and 
distributed resources within a local network. In order to let various kinds of users access NetSim, who may 
be located in different computer environments, a set of requirements were identified and followed during 
the design phase. These declare that the implementation should be: 


* Flexible — Supporting different users with varying computer capacity and properties to utilize the 
system 


* Scalable — In critic situations the number of users must not affect the system capacity 


¢ Platform independent — As much as possible the implementation should be kept platform 
independent 


* Technology independent — The result of our work is primarily the concepts being designed, not 
the implementation. Hence the solution is kept as technology independent as possible 


* Extensible — The infrastructure must allow for further integration of new systems and 
functionality 


All simulation modelling and execution is today performed according to the HLA for purposes of project 
directives. The system is based on a distributed infrastructure implemented with P2P technology, see 2.5 — 
2.6, which provides means for resource sharing and distributed computing among others. It allows users to 
search for, locate and access distributed resources and users in the network. Resources may in this case be 
anything from simulation models to CPU usage. Within NetSim only a few simple tools are currently 
provided, such as a text chat, an application for managing resources, and a graphical modelling tool, in 
which a user may compose HLA federations out of HLA federates residing within the network. A 
snapshot of the graphical M&S tool is shown in figure 2.1. Users can also run and view the composed 
HLA federations from the environment. The execution is performed transparently to the user, within the 
P2P network, through efficient utilization of idle processing capacity in desktop computers. 


2.4 Areas of research 
When designing NetSim, we identified some areas of significance to networked environments and 
network based M&S in particular. We decided to focus on a few, which are: 

* Component-based M&S — Allowing reusable, easily distributed simulations 


¢ Standards and techniques for M&S — Distributed, reusable simulations set high requirements on 
interoperability 


¢ Thin clients — Involving not only PCs and web-based clients in the M&S system, but also 
PocketPCs and others 


* Collaborative environments — Environments that provide a common picture of the problem to 
solve. Involving problems of maintaining consistency and control within the collaboration group 


¢ Resource utilization — Efficient ways of utilizing distributed resources, through efficient resource 
description and allocation 
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Of the issues listed above, the last two have been the key issues in previous and current work. The 
collaborative work is described in chapter 3, and the resource utilization in chapter 4. More technical 
descriptions of these have been presented in two papers [9, 10]. 
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Figure 2.1: Snapshot of graphical modelling tool in NetSim. Users may (collaboratively or not) 
compose HLA federations out of HLA components (federates) residing in the network. 


2.5 Peer-to-Peer Based Resource Sharing 


Peer-to-Peer (P2P) as a concept for computer communication is nothing new. In the early sixties, the 
pioneers of ARPANET formulated their vision of a future computer network comprising host-to-host 
capabilities. In their vision all connected nodes were equal in terms of functionality and could access 
resources from any other computer on the network [11]. These early ideas have not greatly influenced how 
the Internet is used today. The dominating architecture is the client-server model, where resources of 
various kinds tend to accumulate at dedicated centres. Large parts of the Internet remain unused, as 
network traffic around certain spots shows increasing activity. However, in the past years ideas and 
technologies have been put forth that promote the idea of distributing resources through use of P2P 
technologies. The distribution of resources is advantageous from many aspects; it reduces the occurrence 
of bottlenecks, minimizes possible system downtime and increases system availability and robustness etc. 


P2P has definitely made a great impact on how ordinary desktop computers may communicate and 
exchange various resources. This is especially true for the so called file sharing applications, although they 
are heavily questioned in terms of legal property rights. However, some more academic projects have 
successfully confirmed the strength of P2P for distributed computing. The Intel Philanthropic P2P 
program has demonstrated utilization of idle processing capacity in desktop computers to solve problems 
within the medical domain [12], whereas the SETI@Home project represents a successful P2P model for 
distributed computing, used for processing of radio astronomic data [13]. 
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2.6 JXTA 


JXTA is an open-source P2P project, initiated by Sun Microsystems in 2000, providing a standardized and 
platform independent P2P platform [14]. The system is based on XML' messaging through employment of 
six protocols. Any piece of Internet connected hardware implementing these protocols, or a subset of 
them, can participate in a JXTA network. Nodes on the JXTA network are called peers. Peers form 
peergroups, based on common interests and goals, within which the participants share resources [11]. The 
JXTA platform provides a rich set of P2P features, thus simplifying the development of distributed 
systems. 


3. COMPUTER SUPPORTED COLLABORATIVE M&S 


3.1 Computer-based collaboration and M&S 


Since the science and hype of Virtual Reality (VR) broke through, huge interest and activities have been 
conducted within the field. Despite the interest and future-thinking about the area, 3D virtual worlds have 
not yet reached into our offices and everyday lives. VR is instead a part of the larger field of using 
computers to support human-human collaboration, an area which has gained far more usage than VR in 
itself, due to its availability and range of technical possibilities. Groupware, videoconferencing and shared 
project areas are just a few of the kind of products used for these purposes. Computer-based collaboration 
can assist in joining people and organizations in the same environment, allowing people to share not only 
resources but also work areas, tools and environments. Though computer-realized collaboration may never 
represent a substitute for real haman-human work, it can be used for bridging distances and increasing and 
facilitating cooperation. 


These advantages are applicable within other areas as well. If considering collaborative M&S, sometimes 
referred to as CMAS, it could help joining people like software engineers, VV&A expertise and others in a 
common computer environment. With CMAS a project team could cooperate on M&S problems, with 
immediate support from SMEs, and with the customer supervising the activities, no matter if they are 
located on the same place or not. This improves and assures quality of work and enhances work efficiency. 
Within the defence in general, computer-based collaboration is a very interesting issue, since often 
military personnel are spread over long distances. A key feature here is the possibilities of increasing the 
availability of competence and expertise, an issue which could be of considerable importance within critic 
systems for (31 and other domains. 


3.2. + Infrastructure for CMAS in NetSim 


One of the main goals of NetSim is to provide support for collaborative work. If complying with the 
definition of Collaborative Virtual Environments (CVEs) as described in [16], a CVE shall provide shared 
information, tools and communication access, and need not provide a 3D visual environment. The work of 
NetSim focus on constructing an every-day used defence environment, for practical collaborative M&S, 
which is why we dismissed the thoughts of flashy 3D worlds and emphasized on reducing complexity and 
enhancing availability instead. This increases the possibilities of integrating the infrastructure in already 
existing systems, such as for example C3I systems. Thus a flexible and lightweight infrastructure for 
CMAS was designed. A first prototype has been implemented and integrated within the NetSim 
environment. It mainly constitutes a middle layer, between a Java GUI’ and the JXTA P2P network, and is 


' The Extensible Mark-up Language (XML) is a mark-up language designed to describe and encapsulate data. It has become a 
major technique for exchanging data in heterogeneous environments, since it provides a platform and programming language 
neutral data format [15]. 


? GUI- Graphical User Interface, the visual application in which the user interacts with the environment. 
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based on two components. The first component is a core, the Collaboration Core (CC), containing 
functionality for collaborative work, implemented using P2P technology. The second is an HLA coupling 
that provides means of collaborative simulation, and is implemented on top of the CC. These are further 
described below, and were describes in detail in [9]. 


3.2.1 Collaboration Core 


The CC allows users to collaborate on M&S activities, or any kind of activities that the environment 
supports. Currently it provides, among others, functionality for creating, searching for and joining 
collaboration groups’. The collaboration groups are based on the concept of JXTA peer groups, and are 
used for grouping collaboration participants and for utilizing group functionality and mechanisms for 
managing collaboration (described in 3.3). A group provides group specific settings and information, and 
specific services and tools that may be used (collaboratively) within that specific group. The tools can be 
anything from communication means, such as text chats and web-cams, to advanced M&S or other tools. 
The infrastructure allows for further extension and integration of tools but, as mentioned before, it is 
currently just a prototype. The tool that is demonstrated and used today is a simple shared graphical tool, 
in which users may collaboratively compose HLA federations out of HLA federates. Users cooperate 
through using communication tools such as chats and web cams. In the current application, a chat is 
provided within the application and a web cam is used externally. The CC allows participants to share 
views, meaning that all see the same thing at the same time within a work area or tool. Hence, they see the 
same actions and changes at the same time, similar to sharing tools over a network, but in a decentralized 
way through using P2P technology (JXTA). 


3.2.2 HLA coupling 


The second prototype component is the HLA coupling that supplies the user(s) with a graphical interface 
in which the result of the distributed simulation is visualized. All participants in a group see the simulation 
and the same states of the simulation at the same time. This feature is implemented using the HLA 
framework rather than based on P2P technology, for reasons discussed below. Users may stop, play and 
step-forward the simulation, and all group participants receive the same new states if the simulation is 
changed or interacted with. This demonstrative collaborative simulation can be of considerable use for 
military planning, distance education, strategy demonstration, or when using M&S as basis for decision 
support etc. 


3.3. Challenging issues and implemented solutions 


During the work some challenging issues were identified that exist within collaborative systems, and 
which are naturally common for most distributed systems [17], such as mechanisms for maintaining 
information consistency and fault tolerance. It is challenging to synchronize and coordinate actions and 
interactions within a group, i.e. to guarantee that all participants have the same common picture at the 
same time, and that no changes or actions on the same object collide. Another issue was the (collaborative) 
simulation, since different platforms demand various solutions for the same visualization. This requires 
generic interfaces for simulation and tools, which comply with the computer capacity and properties in 
use, problems that are not fully addressed in current work. Moreover network properties may constitute a 
problem due to delays and overhead, another issue not covered yet. Challenging issues that are currently 
considered are presented in brief below. 


3.3.1 General infrastructure for collaboration 


Designing an infrastructure for collaborative work in an efficient way, which is extensible for integration 
of new functionality, is not an easy thing. A usual procedure is to employ a server-centric solution, where 


I 
A user can be a member of any number of groups. 
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the server (or central computer) propagates screen-dumps' of a shared work area (may be a tool) to all 
participants. This is used by products such as VNC’ and NetMeeting’ and can be easily applied but is 
inefficient due to overhead among other things. Our implementation (the CC) provides a more optimized 
solution that is principally distributed and that considers changes in objects’ states, and transmits the state 
changes only, to all participants. On the other hand our solution sets high requirements for integration of 
new tools into the infrastructure, which may have to be generalized in future work. 


The distributed infrastructure was implemented using built-in group functionality in the P2P framework 
JXTA [14]. A new kind of group was created, the CollaborationGroup, which is an implementation that 
extends the group concept and includes services for group functionality etc. When a new group for 
collaboration is created, a new such group is started, instead of an ordinary PeerGroup. When joining a 
collaboration group users receive a handle to a shared communication channel. Thus, all actions produced 
within a group are propagated and managed along this channel. 


3.3.2 Coordinating participant actions 


Collaborative modelling requires real-time interaction. The actions produced must be coordinated and 
synchronized among the participants. For this we applied a coordinator-based scheme, which is a widely 
used solution to the problem. A coordinator represents the node through which all actions are passed and 
coordinated. When a user wishes to perform an action on an object in the shared area, it requests the 
coordinator for permission. If no other user wants to act upon the same object, the request is processed 
immediately and all users receive the new shared state, without causality errors or action conflicts. This 
results in a temporary centralized solution, which is easily implemented but not optimal if a lot of 
information has to be coordinated. Coordination and synchronization would rather be managed in a 
distributed fashion (more complex). Our solution also brings that client synchronization is managed 
immediately, rather than when it is necessarily needed, 1.6. when users need to have the same views. If all 
participants’ views are coordinated only when needed, a better and more scalable implementation would 
be achieved. Thus, these two issues are of concern for current and future work. 


3.3.3. Synchronizing collaborative simulation 


Collaborative simulation does not require such frequent coordination of interactions as other M&S 
activities do, since the user interactions during simulation are most likely simple ones such as stopping or 
pausing the simulation. Thus coordination is not an issue here. In contrast, a high amount of simulation 
information needs to be transmitted to and synchronized between the users, in order to guarantee that all 
users see the same state of the simulation at all times. This means that it may not be possible for the 
information to be continuously synchronized due to the overhead and time delays it may cause. In current 
implementation, the clients’ views are synchronized continuously (synchronously), and would preferably 
be exchanged with more efficient solutions. The issue of effective synchronization was highlighted in 
previous work [9], and is an important part of current work (discussed below). 


3.4 Synchronizing collaboration participants using HLA 


When implementing functionality for collaborative simulation, the design choice was made to use HLA 
instead of JXTA for synchronizing participant visualization and user interaction in the simulation. One of 
the reasons was that HLA provides excellent functionality for time management and means for federation 
synchronization [20]. The HLA coupling was implemented as a layer on top of the CC, as mentioned 
above. Each user application comprises HLA functionality, which acts as an HLA federate, called the 
Visualizer federate. The Visualizer subscribes to the simulation objects and attributes necessary for 


: Screen-dump = a momentary image taken of the screen. 
* VNC — Virtual Network Computing is a free product for sharing work areas [18]. 
Ἵ NetMeeting is a product that allows projects to use shared work areas and tools [19]. 
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visualizing the federation, in order to illustrate the accurate simulation result in the client’s window. The 
Visualizer federates, 1.6. the clients’ views, are synchronized using HLA built-in mechanisms. User 
interactions with the simulation are handled through the Visualizer and are forwarded to the rest of the 
federation. An HLAManager' reflects the interaction event, and makes sure the proper action is processed, 
as for example pausing the federation or stepping it forward. Federations used today are based on time- 
stepped federates and the synchronization is performed synchronously in fixed time intervals. This is 
neither efficient nor scalable, since it results in a great number of synchronization points, no matter if 
anything important has occurred or not. This may in turn cause time delays and unnecessary overhead. 


In order to investigate more efficient ways of synchronizing the federation for our purposes, current work 
emphasizes on facilitating the use of time management (TM) in HLA. A middle layer on top of the 
HLA/RTI is being designed and implementation of it has been initiated, which is somewhat similar to 
approaches made such as [21] and [22]. The layer is included and utilized in each federate, and comprises 
functionality for TM and various synchronization protocols’. A schematic view of this is presented in 
figure 3.1. Protocols that are intended are first of all simple solutions for synchronous and conservative 
simulation, but optimistic protocols are also considered. The layer is designed to relieve the simulation 
developer from some of the HLA specific logic. It will also provide various ways of synchronizing 
federations and estimating performance, which allows flexibility of synchronization protocols. It is 
intended to support us in evaluating and implementing efficient synchronization for the collaborative 
infrastructure, but can be of use within other areas as well. 


Synchronized HLA 
Federation 


[ HLA Runtime Infrastructure 


Figure 3.1: Schematic picture of middle layer for RTI/HLA specific logic. 


3.5 Conclusions 


Applying JXTA P2P functionality for coordinating and supporting collaborative simulation modelling 
turned out to be a good solution. The concept of JXTA peer groups and functionality for groups such as 
membership, authentication, group services etc. was very beneficial within this context. The group concept 
was extended, and gave us the result desired. But JKTA was by the time of work not a fully complete 
technology’, and was not very easily managed. 


' The ALAManager is used for facilitating some functionality within a federation, such as controlling synchronization and 
managing the federation. This is not crucial and everything may be carried out within each federate instead, but it facilitates 
federation development. 

The middle layer is nothing necessary, but it facilitates working procedures, user flexibility and provides extra functionality. 
ἦ The latest version of JXTA is 2.0, a version which the authors of this paper have no practical experience of yet. 
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For the collaborative modelling a centralized coordinator-scheme was used. Since this solution is not 
scalable or efficient, it can be done more efficiently in a decentralized way. This issue is considered in 
current work. Also, the design to use optimized information flows (instead of screen-dumps) proved to be 
good. 


For synchronizing and visualizing the collaborative simulation the HLA framework was applied, 
something that proved useful but needs to be extended regarding flexibility and ease-of-use. 
Synchronizing the federation synchronously showed non-efficient, and an alternative solution is currently 
designed which constitutes a flexible middle layer between HLA and the federates. 


During the work it was pointed out that CMAS can be of considerable use within the defence, such as 
distance education and military planning. This holds for activities that use M&S as basis for decision 
support and situations when presence of SME:s may not be physically possible, but highly desirable etc. 


4 RESOURCE MANAGEMENT 


41 Resource Utilization for Distributed Simulations 


As part of the NetSim environment, a module for execution of HLA federations has been developed based 
on the JXTA P2P platform, described in section 2.6. The main idea of this module, the Distributed 
Resource Management System (DRMS), is to utilize idle processing capacity in a network of workstations 
for distributed simulations. Furthermore, it should provide a distributed repository for storage of 
simulation components and associated documentation. Other projects have explored these possibilities, see 
for example [23], but then often based on the client server model for management of resources and storage 
of simulation components. 


The basic idea of the DRMS is that desktop owners within an organisation download and install a small 
client that under certain circumstances share resources with other connected nodes. There are currently 
three levels of involvements for connected nodes. First, a node may share computing capacity for 
execution of HLA federations, referred to as a computing resource in the following text. Second, a node 
can be part of the distributed repository for sharing of content (HLA federates, documentation etc.). 
Finally, a node may share both computing capacity and content. The desktop owner always has the option 
to withdraw its involvement by changing a switch in the user interface or by closing the client. Therefore, 
the availability of resources on the network is expected to change fast and unpredictably in an Ad-Hoc 
manner. To comply with this the system includes mechanisms for migration, or movement, of federates 
between available computing resources during a federation execution. Furthermore, the dynamic 
characteristics of the network calls for redundancy (replication) in storage of simulation components to 
gain access to the same set of federates at all times. However, this part of the problem has not yet been 
fully addressed in the current implementation. 


A major aspect to consider when implementing any type of P2P based system is discovery and matching 
of resources. The first problem relates to the basic strategy used to discover the presence of other 
nodes/resources on the network. Another problem to handle is how to identify those resources that match 
certain requirements. 


The JXTA platform, and thus the DRMS, supports three different mechanisms for identifying 
nodes/resources, these are [24]: 


¢ No discovery — using this approach, nodes rely on a cache of previously located advertisements 


that describe the features of resources. This is implemented by broadcasting advertisements from 
nodes at regular time intervals 
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¢ Direct discovery — in this case the nodes do not publish any advertisements until they are asked to 
do so, 1.6. until a consumer of resources broadcasts a resource request on the network. This 
strategy is often referred to as flooding 


¢ Indirect discovery — using this approach all nodes publish their advertisements to a centralized 
catalogue. The consumer node locates resources by requesting the catalogue. However, when a 
consumer has identified a producer, the communication is performed directly between involved 
parties 


We have not yet performed any measures of the performance of these three approaches, but this will be 
addressed in future work, where also the new JXTA 2.0 release will be taken into consideration. 


When suitable resources have been identified by consumer peers, the requirements of the requests have to 
be matched against the features of available resources. At present, the implementation includes simple 
mechanisms for this activity. First, the SOMs' of selected federates are automatically matched to assure 
simulation interoperability. Then federates are mapped to available computing resources 1.6. nodes among 
the list of available resources are selected and assigned jobs to execute the federates. The advertisements 
of computing resources contain node specific information, for instance running hardware, software etc. 
Using this information, nodes running the fastest processors are chosen to execute federates. For a more 
technical description of the DRMS see [10]. 


The present approach of matching simulation components to form simulations and mapping individual 
components to computing resources is rather rudimentary. There is a need to enable matching of 
simulation components, not only at the architectural level (matching of SOMs), but also at a higher level. 
Furthermore, it is also important to describe a simulation component in terms of its requirements on the 
execution environment, and likewise describe the features that a computing resource provides for a 
simulation component. This calls for a better way of managing meta-descriptions of resources within the 
NetSim environment, to facilitate efficient searching, matching and execution. 


4.2 Describing Resources 


This section gives an overview of ongoing and future research topics, aimed at extending the support for 
metadata in the NetSim environment. The employment of meta-descriptions of resources within the 
NetSim environment is especially pronounced during three activities; searching for simulation 
components, matching simulation components and during execution of simulations. The role of metadata 
also differs greatly between these activities, which will be explained below. However, there are no solid 
boundaries between the uses of metadata in these activities. Certain types of metadata may be applicable 
in all three cases. 


4.2.1 Searching for components 


In this activity the user/users of the NetSim environment searches for available simulation components or 
previously assembled simulations. The basic requirement on metadata supporting this process is a well 
defined class structure, identifying subclass/superclass relations. This enables simple queries like “all 
airplanes” or “all fixed-wing aircrafts”, which yields all components which are subclasses of airplane or 
fixed-wing aircraft respectively. However, note that this classification is not equal to the implementation 
related object class structure. Furthermore, the components should be described in terms of a system-of- 
systems view where, if applicable, a component’s relations with other components are defined. For 
instance describing that system A and system B may integrate to form the superior system C. Finally, the 


' SOM is the short term for Simulation Object model”, and is the documentation and definition of a federate’s all characteristics 
and possible interactions etc. 
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metadata infrastructure should support descriptions of roles or capabilities, which enable searches in the 
form of “air based transportation” or “underwater surveillance”. 


4.2.2. Matching components 


This activity represents the attempt to compose simulations out of a number of components, i.e. 
component based development. This area is sometimes labelled composability and has been investigated 
extensively to promote model reuse and interoperability. According to [25] composability is 


“the ability to combine and recombine components into different simulation systems for 
different purposes.” 


Irrespective of matching at the simulation architectural level, for instance matching of SOMs in the case of 
HLA, an environment supporting component based simulation development should include extensive 
metadata. This is to guarantee the composition of valid simulations at all levels. [26] outlines some of the 
fundamental requirements on metadata to support composability, namely; 


Information about the model as a software component: 


¢ Programming language 
* Communication protocol 
¢ Location of component 


Information about the model as a simulation component: 


¢ Spatial resolution 

« Aggregation 

¢« Temporal resolution 
* Fidelity 


* Required services 


4.2.2 Executing simulation 


This final activity involves mapping simulation components to computing resources prior to and during 
federation execution, i.e. assign jobs to various nodes in the network. Metadata that should support this 
process include running hardware and software on the computing resources and a set of requirements 
imposed by the simulation components. These requirements consist of information such as; what platform 
is needed to run the component? Is a specific runtime-environment needed to run the component? How 
computing intensive is the component? etc. Note that this process is not only required prior to the 
execution. Since the allocation of computing resources is not static, it is necessary to perform rescheduling 
from time to time. 


4.2.4 Metadata framework 


In order to create a foundation (or framework) for metadata, to support resource consuming systems 
(M&S and C3I systems) in various ways, a number of components are required: 


¢ Meta-language — formal semantics and syntax, expressing shared and common understanding of a 
domain 


¢ Metadata repository — supporting uploading/downloading of metadata through standardized 
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protocols (http, SOAP etc.), consistency checking and version control 
* Query language — supporting complex queries on the metadata 


Figure 4.1 outlines a conceptual view of a framework for metadata supporting efficient searching, 
matching and execution within the NetSim environment. The central component of this system is a 
repository where the descriptions of resources on the network, simulation components, data and 
computing resources are stored. The resources should be annotated according to a standard for data 
representation augmented with the shared knowledge of the domain. Activities within the NetSim 
environment are then supported by extraction of meta-descriptions from the repository, followed by semi- 
automated reasoning using the knowledge expressed by these descriptions 


There are a number of efforts that could provide a basis for our envisioned metadata framework, for 
instance the Resource Description Framework (RDF) [27], the Web Ontology Language (OWL) [28] 
promoted by the W3C [27] or the DAML-S initiative, supporting semantic mark-up of Web services [29]. 
These approaches support the creation of specialized schemas, to represent the knowledge within a 
domain, which are used to describe various resources on the Web. There are also several efforts within the 
semantic web research community that build on these concepts to provide frameworks for meta-data 
driven solutions. Work has been carried out to support RDF based metadata in JXTA, including query, 
replication, mapping and annotation services [30]. Several other projects have constructed dedicated RDF 
databases with support for various RDF query languages, se for example [31] and [32]. The features of 
these approaches are diverse, ranging from stand-alone to distributed databases or P2P-style systems. 


NetSim 


Search Match Execute 


Query Support 
Knowledge 


Data Representation 


t t 
a a 


Simulation Input Computing 
Components Data Resources 


Figure 4.1. Conceptual view of a proposed framework for metadata enabling efficient searching, 
matching and execution within the NetSim environment. 


43 Conclusions 


From our experiences developing the DRMS we consider the lack of supporting metadata within the 
NetSim environment is of major concern. The support for meta-description of resources within JXTA in 
general is relatively weak, mainly key-word based searches of resource advertisements. We envision a 
layer on-top of JKTA supporting more complex descriptions of resources derived from a shared view. The 
meta-data layer should support the users of NetSim in simplifying identification and matching of resources 
as well as for optimization of the federation execution. We consider that the work carried out within the 
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semantic web community is of great interest in this respect. Concepts from this area could be applied to 
model knowledge and _ provide extensive meta-descriptions of resources to _ enable 
automatic/semiautomatic localisation, selection, composition and execution of various resources. 


5 SUMMARY ἃ CONCLUSIONS 


At the Department of Systems Modelling, Swedish Defence Research Agency, ongoing research is 
targeting the role of network/web based technologies in M&S, to support defence communities in their 
work. During the first phase of this research, focus has been on efficient resource sharing and means of 
computer collaboration. A prototype, named NetSim, has been implemented to investigate and 
demonstrate these issues, based on the open-source Peer-to-Peer platform JXTA. The NetSim prototype 
allows people at disperse locations to collaborate in creating various HLA simulations in a component- 
based manner. Executions of the assembled simulations utilize idle processing capacity of desktops 
currently connected to the system. As the NetSim is based on Peer-to-Peer concepts, and not dependant on 
a single server or desktop machine within the network, the system is to some extent more robust and fault- 
tolerant than a client-server solution. However the synchronization of collaboration participants is partly 
based on centralized control, which proved non-efficient and non-scalable. JXTA was at the time of 
implementation not a fully mature technology, which affected the overall performance of NetSim to some 
extent. For example, it lacks of support for extensive meta-descriptions of available resources on the 
network. However it should be pointed out that JXTA provides a rich set of P2P features, suitable for 
implementation of distributed systems such as NetSim. Future research will address distributed algorithms 
for synchronisation of collaborative work and a more flexible and extendable approach to resource 
management. 
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ABSTRACT 


This paper presents part of the work that is performed internally for INTRACOM 
Defense Department. As an integral part of this work, a Battle Management 
System (INTRACOM iBMS) and a Computer Generated Forces System 
(produced by INTRACOM for this purpose) are linked together. As an example of 
Lessons learnt from past experience in linking M&S and C3/, the paper discusses 
the approach that was used to connect the two systems. 


Paper presented at the MSG-022/SY-003 Conference on “C3I and M&S Interoperability”, 
held in Antalya, Turkey, 9-10 October 2003, and published in RTO-MP-MSG-022. 
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BACKGROUND 


The goal of the performed work is to demonstrate the capability to couple a 
Command and Control system together with a CGF system. There are two 
perspectives on the usefulness of this. From the CGF point of view, the use of a 
C3lS as an interface device, optimizes the workload of the instructors and 
animators of tactical environment. It also reproduces current operational 


environment especially for training audience. 


From the C3lS point of view, interoperability with a CGF can offer new 
intelligent services in war-gaming and planning, reducing the need for 
cumbersome pre-battle group-working sessions. 

Simulation systems can stimulate the C2 system by providing data that simulates 
the 'real-world'. This information now appears to have been received from peer 
C2 systems. In this way a simulated COP (Common Operational Picture) is 
created that is based on a simulation scenario. Applications of this technique are: 
assessment of C2 systems (performance, user interface etc.), assessment of C2 
operator capabilities or training of C2 operators. 

The simulation can provide the C2 operator with operational decision support by 
executing ‘what-if! scenarii. Simulated systems can be ‘initialised’ from the 
existing COP in the operational C2 system and a simulation run can be started 
based on this information. The simulated scenarios supports the operator in his 
decision making process (e.g. mission planning or assessment of alternative 
COA's). 

Simulations can assist the C2 staff in understanding the prepared mission plan 
(mission rehearsal) and refining the plans before the operation is executed. 
Commanders will be able to identify the aspects of the plan that will be crucial for 
success or failure. 

Furthermore, new or experimental parts for an existing C2 system can be 
evaluated before purchase or even before full development by replacing an 
existing component of the C2 system with an embedded or external simulation. 
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Speech recognition/voice synthesis techniques has been taken under 
investigation as alternatives for sending/receiving 


commands/reports/acknowledgements. 


C31 System 


oe METEOVIGH GL) = [FOIPA®. SYNTET. "Ὁ 
| » ΚΣ z251708141086000 | νη νον ὃ 
Ege 
4 ; 


, ae NY 


14 
(Δὰν 
iy 


an « 


Figure 1 A screenshot of INTRACOM BMS 


The most fundamental function of the C3l used (namely iBMS) is to provide the 
tactical picture to the commanders (all levels) and the driver. A map is displayed, 
containing dynamically changing geo-registered information, about everything 
that concerns the specific user. 

Tactical Situation Update utility, allows users to manually refresh the tactical 
picture of the entire battalion, through a number of mechanisms. This has only to 
do with information regarding the enemy forces. 

Logistics functionality is the function providing information about vehicle’s 
systems, ammunition, fuel and personnel information. This function is also valid 
for echelon commanders, where the logistics of the respected echelon can be 
viewed. 
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C3l also provides Tactical planning. An echelon commander can study a plan 
received from his superior officer (next level in command), create his\her own 
plan and send it to his subordinates. 

Finally, communication facilities allow messaging with other vehicles, control of 


transmission media etc. 


BMS advantages 


Using conventional techniques, i.e. war-gaming in order to elaborate the 
Operations Order, is a very cumbersome process. Imagine a couple of vehicles 
moving next to each other and setting a tent to accommodate all the involved 
parties. They form, what is known as a ‘cluster’. In that cluster, the involved 
parties draw alternative plans on thin layers of film, positioned on top of the paper 
map. 

With INTRACOM C3l (BMS) we get a completely different situation. First of all, 
there is no need to form any physical clusters any more, that on top of everything 
else they can be easy targets for the enemy. Each involved party can take part in 
this group-working process remotely, through the use of the BMS. The BMS 
offers a 3-dimensional view of the map, allowing navigation in all directions. The 
user can select ego-centric and exo-centric views. Of course, whatever was 
possible on a 2-D map is still possible to do with the 3-D view of the map, like 
measuring distances, determining Line Of Sight (LOS) etc. Each individual party 
involved in the war-gaming exercise, places his units and he can move them or 
delete them to elaborate on the Operations Order. The other involved parties can 
then see the move of the first player and respond with their moves. It is 
something like playing chess or bridge on the internet. Of course, all this can be 
recorded as a scenario and played back whenever it is needed. 
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How CGF comes into the game? 


However, not everything can be dealt efficiently through this group-working 
process. There are situations, where real expert play is required. There may be a 
need for additional dimensions of the situation to be considered, like for instance 
messages to be exchanged or logistics situations during the game. Then, an 
opponent like the computer might be used to war-game with. This time, the 
metaphor is simply like playing chess against the computer. 


In order to get intelligent behaviour like this, the use of a Computer Generated 
Forces (CGF) or more generally speaking of a simulation federation, was 
preferred. How to do that however? 

There are various challenges. 

First of all, both systems (the BMS and the CGF) should run on the same single 
computer of a vehicle. This is not as easy as it looks. Keep in mind that it is very 
possible to deal with military equipment that needs to meet the toughest 
environmental standards. Such hardware must be able to survive in temperature 
ranges like -40 C to +70 C, making us think about what happens to the operator 
at that time. It should come to no surprise then, that the performance of such 
hardware is not really state-of-the-art and therefore, hosting a BMS and a CGF 
application at the same time needs at least some attention. 

Secondly it is clear that there must be a way to interface the two systems. As 
something like this is not available today, it was obvious that an interface should 
be developed. But before thinking about the right interface approach, we should 
consider the requirements to build an interface. Luckily, at INTRACOM, problems 
like access to source code or documentation weren't met, as there is a number of 
small-scale in-house CGF systems, in order to be used for tests together with the 
BMS. Furthermore, XML packages are numerous and free for usage. 
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Introduction to XML technology 


XML is a meta-language that supports the customized definition of the 
components of a language (syntax, data types, vocabulary, and operators) 
needed to support the interchange of data for a particular application 
environment. XML provides a basis for the development of data transmission 
formats that are transmitter and recipient independent and that can be 
completely self-describing and self-contained. These inherent XML capabilities 
permit federates to be added to a federation with a minimum of software 
development and with high confidence that information exchanged between 
federates will be accurately represented, transmitted, and received within the 
federation. 


XML permits the simulation community to move to a deeper level of specification 
by providing data definitions and formats that are flexible, independent, and 


comprehensive. 


Extensible Markup Language (XML) can make its contribution to distributed 
simulation by providing an interoperable and open format for data representation 
and be of special use in the development and maintenance of computer- 
generated actors (CGAs). 


Each application-specific definition is contained within a Document Type 
Definition (DTD). The DTD describes a vocabulary and syntax for the data 
(document) to be transmitted. XML provides a basis for the development of data 
transmission formats that are transmitter and recipient independent and that are 
completely self-describing and self-contained. 


Bridging a BMS and a CGF using XML 
NATO RTO-MP-MSG-022, Antalya, 10 October 2003 


ts NATO 
OTAN = 


ORGANIZATION 


Why XML? 

Several factors indicate that XML will continue to grow in popularity and usage. 
First, XML is a flexible approach to formatting documents. The XML capability to 
define and use custom tags and the minimal requirements imposed by XML on 
the markup language being designed give us great confidence that we can 
express the transmission format robustly within the boundaries of the language. 
second, XML is widely used and is standardized; therefore, the basic 
components of the language are stable and well understood. 

Third, XML is precise, it has a well defined set of rules for describing a document 
containing the markup components and for ordering the contents of a document 
but does not specify semantics. As a result, XML provides the basis for 
developing a common data format that is robust in the face of data corruption, 
self-describing in terms of tag meaning, and extensible to accommodate 
unforeseen data requirements. 

Fourth, because XML supports the definition of custom tag-sets and custom 
document structures that are completely contained within the document, an XML- 
based specification for CGA state can be automatically searched and 
categorized by computer programs instead of manually. 

Fifth, XML provides interoperability between different platforms. 

Finally, XML supports the creation and use of multi-part, distributed documents 
and supports interchange of data between applications. 
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Approach followed 
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Figure 2 XML Approach for interfacing C2 world and CGF world 


Technically speaking, the purpose is to connect a C3l operator to a constructive 
simulation. Both systems agree on common XML formats that should be 
“exchanged” (each system has to understand what the other has sent) and on 
common content (vocabulary). Vocabulary means the possible types of 
messages that are going to be used in a scenario. Messages like ‘Move order’, 
‘Logistics report’, ‘Situation Report request’, ‘Order Of Battle’ etc. are agreed 
upon. The set of messages handled by a CGF is of course, only a subset of 
those of a BMS, as they do not include free text messages. 


The data flow between the C3IS and the CGF relies on XML technology. The 
components addressing this interface share a common directory (using File 
System, eventually mounted in case of different machines), writing and/or 


reading XML files that depict messages that are being exchanged. 
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A synchronization-pool mechanism (see Figure 2) is used. Both systems agree on 
the directories that they shall be shared. 
o One directory (let’s call it C3_dir) is used by C3l system to write its 
commands. CGF reads from this directory. 
o One directory (let’s call it CGF_dir) is used by CGF system to write its 
reports to C3l. C3l reads from this directory. 
A semaphore file is used. When an application (C3l or CGF) wants to read/write 
from/to a directory it first checks for a semaphore. If the semaphore is there, then 
the application removes the semaphore, does its job (writes new files/reads files) 
and then puts the semaphore back to make the directory usable by the other 
application. 


The main advantage of this solution is to ensure generic and device-independent 
simulation messages in order to support information coming from and going to 
the two interfaces that were used; the command and control system and a vocal 
interface. The two interfaces (from the CGF point of view) are independent one 
from another and each remains functional without the other. This allows to easily 
build scalable and multi-level systems and to deploy them depending on the 
training needs. Both interfaces define some requirements on this CGF in order to 
ensure consistency between requirements addressing CGF. As the intermediate 
XML layer controls the data entities and ORBAT of all involved sides, it is 
possible that the C3lS initiates the loading of those data. At the application level, 
that means that the C3IS is capable of playing what-if scenarii without the need 


for war-gaming sessions involving a number of human operators. 


Types of exchanged messages 
Here is a list with the type of messages that are exchanged during interaction 
between the two systems: 

e C3l to CGF 
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o C3lcan request a “Logistics Report” from unit or group of units. 

o C3l can send a “Move” order to a group of units 
(company/squadron/platoon/etc.) with information about waypoints 
that must be followed, type of formation and speed they should 
keep. 

e CGF to C3! 

o CGF sends an “Acknowledgement message” for each command it 
receives from C3l. 

o CGF sends a “Logistics Report” for the unit or group of units from 
which C3l requested information. 

o CGF may send “Enemy positions report”. 

o CGF may send its ORBAT (OR of BATIle), so that C31 to be able to 
update the units representation on its map. 

o CGF may send “Under Attack” for each of the units that are under 
attack by enemy forces. 


C3IS enrichment 


Utilization of Voice Synthesis/Recognition technology can enrich the C3l system 

— A Voice Synthesis component could produce voice that 
corresponds to a received message. This would make the 
interaction between C3I-CGF look closer to reality. For example, 
when C3l receives an “Under Attack” message from CGF a voice 
could be produced like “Under Attack from 1112 unit”. 

— A Voice Recognition component would be useful as alternative 
way of sending a command. E.g. the C3l commander could send a 
request for logistics report either using the graphical interface of 
C3l or through his/her voice (using the vocal part of C31). 
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CONCLUSION 


XML was successfully used on a C3l to assist the user in his decision making 
process and in understanding and refining mission plans. 

Building such an interface using XML, a common format and content is required, 
as well as a way of synchronising the two systems. 

The main advantage of this solution is that it ensures generic and device- 
independent simulation messages in order to support information coming from 
and going to the two interfaces that are used; the Command and Control system 
and the Voice Recognizer. The two interfaces (from the CGF point of view) are 
independent one from another and each remains functional without the other. 
This allows to easily build scalable and multi-level systems and to deploy them 
depending on the training needs. Both interfaces define some requirements on 
this CGF in order to ensure consistency between requirements addressing CGF. 
As the intermediate XML layer controls the data entities and ORBAT of all 
involved sides, it is possible that the C3l initiates the loading of those data. At the 
application level, that means that the C3l is capable of playing what-if scenarii 
without the need for war-gaming sessions involving a number of human 
operators. 

The approach has proved to be fruitful as the communication between the C3IS 
and the CGF is successful using both the messaging and vocal interface. 

The approach is proven definitely flexible and relatively easy to achieve. 
However, it is an interface devoted to the specific pair of systems and cannot be 
reused for any selection of systems (namely the mechanism and its working 
parts are not like a template that can be used between a different C3l and CGF 
system). 
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Abbreviations: 


Battle Management System 


Command Control and Communication 
Information / System 


Computer Generated Actors 
Computer Generated Forces 
Courses Of Action 

Common Operational Picture 
Line Of Sight 

Modeling and Simulation 
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Soldier System Information Interoperability 
Abstract 


This paper overviews the standardisation work being undertaken by NATO Topical Group 1, Soldier System 
Interoperability. The Group’s work on systems analysis for dismounted operations is described, with special 
empahsis on the approach being taken to C4I. The rationale for the development of a STANAG to facilitate 
low-level tactical data exchange is also described, including an overview of the experimental and 
demonstration work being undertaken to inform STANAG development. 


Mr Peter Dooley 
Consultant systems engineer QinetiQ Ltd, 
Building H7, MoD Fort Halstead, Sevenoaks, Kent, TN14 7BP, UK 


pjdooley@qinetiq.com 


NATO Topical Group 1 


This paper has been prepared on behalf of NATO Topical Group 1 (TG/1) at the direction of the UK 
Ministry of Defence Future Integrated Soldier Technology (FIST) Integrated Project Team (IPT). TG/1 is 
a Level 2 Group and is concerned with soldier system interoperability. The Group is open to and attended 
by Partners. Australia has been granted observer status. The TG/1 objectives set by the NATO Armaments 
Advisory Group (NAAG) are as follows: 


a. to develop STANAGs in 5 focus areas; 
b. to foster information exchange on soldier systems; 
ο. to broaden and deepen interaction between groups in the NAAG. 


Develop STANAG in 5 focus areas: These focus areas are as follows: 


a. Power — a STANAG is currently being finalised, addressing dismounted soldier electrical supply 
systems. 
Architecture — focusing on electrical interface and data protocols. 
ο. Clothing, equipment & protection — seeking to establish current standardisation work already 
underway within NAAG. 
: Weapons -- ἃ newly defined area of work. 
6. C4I -- concentrating on the exchange of low level tactical information exchange. 


Foster information exchange on soldier systems: ΤΟΊ] brings together the nations with major 
programmes and those seeking to select solutions, or elements of the solution, from the ‘major players’. 
Standardisation increases the potential to achieve this intent. 


Broaden and deepen interaction between groups in the NAAG: TG/1's role is to ensure that work 
underway elsewhere in the NATO is focussed towards meeting the needs of the dismounted soldier. This 
implies the need to link with other relevant NATO Groups, where issues such as vehicle system interfaces 
and combat identification are being addressed. 


TG/1 evolved from the former LG3 WGE3 and has a mandate to operate until Autumn 2004. Work under 
LG3 WGE3 included a task to provide guidance to the modelling and simulation community (principally 
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LG3 WGE4). As a predominantly User-based group with technical support, it was considered important to 
provide guidance to the modelling and simulation community to ensure that outputs were expressed in 
terms readily understood by the military. That work proceeded with a systems analysis of dismounted 
tasks and generated an effectiveness measurement framework with an emphasis on defining Measures of 
Effectiveness (MoEs) at the mission level. The focus was to ensure that the modelling and simulation 
community could focus its work and produce outputs to which TG/1 could relate. The work has been 
termed ‘NATO measurement framework’. 


As part of this work, TG/1 attempted to better understand C4I MoEs. The next section overviews the 
systems analysis conducted to identify MoEs associated with company level and below, before exploring 
our C4]-related analysis. The development of a STANAG to define data formats for low-level tactical data 
exchange is then described. 


Low level mission analysis - overview 


Analysis has been undertaken of dismounted operations, typically at Company level and below. Missions 
have been decomposed into component vignettes. Listed below are some of the component vignettes that 
have been identified for a mission ‘to attack and hold an enemy position’: 


planning and preparation; 
close target recce; 
advance; 

attack; 

re-org; 

defence; 

re-org. 


gm mhonoges 


Collective Measures of Effectiveness (CMoEs) have been defined for each of these vignettes. As and 
example, the close target recce vignette could have the following CMoEs: 


detection avoidance (Y/N); 

consumables employed; 

time taken (as in orders?); 

casualties; 

quality of information obtained (subjective); 

physical and mental sate of soldiers employed (1.6. their ability to continue operations). 


mo naoges 


At the mission level, the CMoEs would be selected from those defined for the vignettes in the context of 
the orders set. Some of the vignette level CMoEs would become unimportant at the mission level and 
would not be employed (e.g. detection avoidance during close target recce). For the example mission, 
these could be: 


own casualties; 

other soldier's condition; 

consumables; 

achieving key event timings specified in orders. 


aoe 


The relative importance of CMoEs will vary according to the mission; e.g. the situation may determine 
that holding an objective for the specified time is more important than casualties suffered. 


The measurement framework also indicates how the relationship between the soldier and his equipment 


within the physical and organisation environments contributre to providing a level of capability to 
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undertke a task. Actual equipment Measures of Performance are thus modified to bring a certain level of 
capability with which to undertake a task. This is shown in Figure 1. 


Level 
Contribution to force 
bilit 
capability 0 
Impact on mission 
outcome la 
Collective effectiveness 
achieved from 
; 1b 
aggregation of level 2 
tasks 
Soldier(s) effectiveness 2a 
for individual tasks within 
mission 
Soldier(s) capability for 2b 


a particular task 


Environmental} (Equipment associated 3 
(organisational) ith enhancing soldier 


capability for a particular 


; Environmental 
Soldier (physical) 


Sub-modules 


Basic element 
Hardware components 


Figure 1: Measurement framework levels 
Low level mission analysis — C4I aspects 
The NATO measurement framework has established effectiveness principles relating to command and 
control (C2). If C4I equipment is to be evaluated, perhaps during field trials, then a data collection 
approach must be defined. Analysis has identified the following general C2-related capabilities: 


a. the ability to receive and pass on orders prior to the start of the mission (orders pre-mission); 


b. the ability to navigate (navigation); 
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ο. the ability to achieve a level of direct situational awareness consistent with the needs of the mission 
(direct situational awareness); 


d. the ability to achieve a level of indirect situational awareness consistent with the needs of the 
mission (indirect situational awareness); 


6. the ability to provide an adequate post mission debrief (debrief); 
f. the ability to operate covertly (detection avoidance); 
g. the ability to adapt the plan as a result of changing circumstances that develop after the mission has 


commenced (‘command agility’); 
h. the ability to achieve key event timings (key event timings); 


i. the ability to re-organise the soldiers after the completion of the mission in a timely manner 
(reorganisation time). 


Command agility 


For all but one of the above capabilities, the MoEs associated can be defined with relative ease. Often, but 
not exclusively, the CMoE associated with C4I is time. However, C4I could actually make a mission 
longer, if a more covert route was established that allowed an enemy position to be taken by surprise. 
Here, the effectiveness of the C4I would derive from a reduction of own casualties. 


The most challenging C4I capability to analyse was point g, "the ability to adapt the plan as a result of 
changing circumstances that develop after the mission has commenced". TG/1 have termed this ‘C2 
agility’. If a mission proceeded according to the original plan, it could be argued the actual conduct of the 
mission could have been completed without the commander. However, it is when unforeseen, or 
unpredicted, changes to the mission have to be managed that the commander, supported by C4I, must 
intervene. Qualitative assessment of the performance of C2 during such situations can be assessed, using a 
structure that seeks to analyse the C2 process when managing the situation. 


Command agility analysis is conducted by applying the following questions to events that required 
commander intervention: 


a. Did the mission go according to the original plan? 

b. If not, what caused the need to deviate from the plan? 

ο. Was this change communicated efficiently to those concerned? Was the change implemented as 
intended? 

d. Was the commander’s situational awareness adequate when the change was defined? 

6. If not, what information did the commander need and what would have been the best way of 


accessing this information? 
f. Could anything be done to improve the way the change was implemented? 
g. Did the change, as implemented, have a critical impact on the outcome? 


h. Are there any other material factors that affected C2 flexibility? 
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After action reviews of UK C4I field trials, provided responses to the above analysis, from each 
commander. The technique has been used to establish effectiveness, both with current C4I and then with 
enhanced systems. Often it is possible to demonstrate that, when the re-direction was inadequately 
implemented, it could be linked either with the failure of the mission or reduced collective effectiveness. 
Although a subjective process, it does provide a basis for analysis of the effectiveness of C4I. 


Analysis subsequently concluded that, when assessing the outcome of a mission, it was necessary to 
include a factor that related to the degree of difficulty imposed on the commander by external events that 
occurred during the conduct of that mission. Only in this way can (41 be accurately addressed. 


The CMoE framework has been used extensively in national trials as a qualitative/quantitative mechanism 
to assess performance of capability. The work has been published by NAAG [1] but requires updating, 
following experience gained in its use on field trials. 


Requirement for low-level tactical data exchange 


This section of the paper addresses the TG/1 C4I team’s work on production of a STANAG relating to 
data formats for achieving low-level tactical interoperability. 


One might ask where the requirement is for sharing information at such a low level? There is no NATO 
requirement at present but the TG/1 C4I team is tasked with exploring the ‘art of the possible’. It is then 
down to NATO to decide whether the capabilities offered will be employed. However, there is, at present, 
a high degree of force mixing within NATO operations. Dutch platoons operate within UK companies 
during peace keeping. Furthermore, the sharing of tactical information across force boundaries will 
provide an increase in situational awareness. This may well contribute to a reduction in the occurrence of 
potentially fratricidal situations. In exploring the art of the possible, TG/1 is establishing other associated 
challenges that must be met, particularly those related to security and radio bearers. These are listed 
below. There are other challenges related to NATO itself that are also being addressed. The key one is 
ensuring that TG/1's work does not duplicate work already being undertaken elsewhere within the NATO 
system. TG/1 aims to ensure that the data model that is being developed is correctly placed within the 
overall NATO data model. This is very complex and work has only recently commenced. 


Approach taken to development of a STANAG for low-level tactical data 
interoperability 


The tactical information interoperability STANAG is being developed in parallel with an experimental 
and demonstration programme. The scope of tactical data exchange would include: 


positional data; 

force boundaries; 

positions of key features e.g. minefields; 
text information; 

lines of departure; 

APP6a symbols. 


mo noge 


Relevant tactical data needs to have been identified. Many of these are addressed in APP6a. The 
possibility of updating APP6a to include further types is being explored. TG/1 has listed all the symbols 
and related information that are of use to enable awareness sharing at the lower level. Many of these are 
covered by APP6a but some are not. These TG/1 is seeking to have included. 


TG/1's approach has been to generate what can be termed ‘the NATO data library’. This is a definition of 
how, in a country-independent format, tactical objects and their attributes should be described. 
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Example information includes: 


co-ordinate (latitude/longitude as floating point, based on WGS84 datum grid). 
object identity size (integer). 

object identity (e.g. callsign as text). 

object nation (e.g. UK as fixed text field of 2 characters). 

date/time (e.g. DDMMYYhhmmss as fixed text field of 12 characters). 


ooo FP 


The STANAG does not intend to specify how an individual country will actually display an item of 
tactical data, if it does not wish to use it or finds that APP6a symbols are not suited to small scale 
electronic map displays. Where symbols have an APP6a identity number, that identity number defines the 
object in TG/1's approach and hence the reason an update to APP6a is needed. 


Having defined how information should be described, it was then necessary to seek a format to send the 
information between one national system and another. This data definition is described using Backus-Naur 
Form (BNF). The definition, together with the object/attribute list, provides the basis for the creation of an 
appropriate interchange data reader and writer. This is what TG/1 has termed in the NATO library and this 
is a country-neutral definition. 


For the purpose of the experimental programme, a NATO library code has been generated to suit three 
different operating systems used in the experimental and demonstration programme (WINDOWS 98/NT, 
WINDOWS CE and Linux). 


TG/1 is linked with the International Collaborative Opportunities Group (ICOG), to further the 
achievement of low-level tactical data interoperability. The ICOG nations are UK, US, Germany, France 
and Italy, but all NATO nations and Partners are invited to joint TG/1 / ICOG experimental workshops. 
The NATO nations actively participating in the experimental and demonstration programme are Canada, 
France, Germany, Norway, UK and the US (Army and Marines). Some nations employ prototype systems, 
whilst others participate with research equipment. All use different map applications. Each nation has 
written a file that allows it to read from and write to the neutral format. 


Experiments are conducted inside, with systems co-located around a table. The mechanism for exchange 
between national systems (for experimental and demonstration purposes) has been via WLAN 802.11b. 
The tactical information for exchange is generated within a map application layer (typically about 1Kb file 
size). The information therein is then written to the NATO neutral format and sent as an attachment to an 
e-mail, addressed to one or more nations participating in the experiment. On receipt, the receiving national 
system automatically opens the attachment, feeds the neutrally formatted information into its conversion 
program and then displays the received information correctly geo-referenced. 


Progress in experimental programme/planned activites 


Successful data exchange has been achieved between UK research C4I sets and C4I equipment from 
Canada, Norway and France and the US. The level of tactical information is superficial at this stage, but it 
is sufficient to establish and check principles. In 2002, using an earlier version of the library, the UK and 
Canada exchanged information by way of floppy disk. Figure 2 provides a typical example of successful 
exchange between the UK and Norway, both with different operating systems and map applications. The 
Norwegian system (left) displays UK tactical information and the UK system (right) displays both UK 
tactical data and that received from Norway. At a joint ICOG / ΤΟΙ] C4I meeting in Oslo in June 2003, 
exchange over WLAN was, to some degree, achieved between Norway, France and the US. Further 
experimental workshops are planned between writing and delivery of this paper. The TG/1 C4I team will 
provide a demonstration of tactical information interoperability to the full TG/1 meeting to be held in 


27 RTO-MP-MSG-022: C3/ ἃ Modelling and Simulation Interoperability 12-6 


NIZAT 


Rome (22 October 2003) and to the NAAG in Autumn 2004. Other nations, including a Partner nation, are 
beginning to become active in the experimental programme. It is anticipated that the number of nations 
participating in the NAAG demonstration may reach ten. The experimental/demonstration programme has 
assisted greatly in de-risking the STANAG, scheduled for publication in Autumn 2004. 


Challenges to achieving low level tactical data exchange 


Clearly, establishing the formats for data exchange is a relatively straightforward task; actually achieving 
the tactical interoperability on the ground may not be so. Tactical exchange, in any ‘interoperable session’, 
is likely to be limited to just two nations, but this need not be the case. The challenges that the combined 
group is addressing include the following: 


communications bearer; 

security; 

encryption; 

unauthorised use of systems; 

information conflict; 

situating TG1's data model within the overall NAAG data model; 
STANAG maintenance. 


mmoaoc cp 


Communications bearer: With software programmable radios universally employed, exchange is, 
theoretically, ‘easily’ possible. The C4I team has been exploring the loaning of a radio to an adjacent force 
and has ensured the necessary interface information is embedded in TG/1 architecture STANAG should 
this the approach selected. 


| 


Sa 
I > 
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Figure 2: Norway (left) - UK (right) tac data exchange using WLAN March 2003 
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Alternatively, the exchange could, in theory, be achieved today using a WLAN-based solution, if 
range/bandwidth performance become adequate. 


Security: Here the issues associated with the connection of potentially secure systems have addressed. 
There are the associated problems of virus control, the potential to ‘snoop’ on the other system. 


Encryption: Encryption can be applied but this will, inevitably, increase the data traffic, with the penalty 
of added bandwidth being required. Some nations may consider that low-level data that will become ‘time 
expired’ quickly and this could be sent with minimal or no encryption over radios with relatively short 
ranges. 


Unauthorised use of systems: TG/1 is addressing issues such as system integrity. This includes problems 
associated with the unauthorised use of captured radios; an enemy could not gain tactical advantage from 
knowledge of "blue" positions and intentions but also has the potential to overload networks. 


Information conflict: Clearly the potential exists to duplicate information being passed between forces at 
a higher level. If TG/1's system were implemented, it could be that that information received across the 
force boundary should not passed up the command chain automatically. 


Situating the TG/1 data model within the overall NATO data model: A significant challenge that is 
being addressed is ‘why is another data model needed?’ The potential exists to use, for example, the 
Multinational Interoperability Programme (MIP) data model or, possibly, a derivative thereof, or an 
alternative NATO data model. The TG/1 / ICOG C4I team is establishing whether any fundamental 
differences exist between TG/1's proposed model and those that already exist. There is a concern that, as 
‘soldier carried’ systems have limited computing power, driven by the weight/power issue and bandwidth 
limitations exist with tactical radios, a specifically tailored data model may be necessary. This need must 
be demonstrated. 


STANAG maintenance: Given that computing and operating systems may be frequently updated, 
consideration has been given to the use of a programming language such as XML as these are operating 
system independent. XML may be the way to go, provided it does not create an unnecessarily high data- 
passing requirement. If XML is selected, there is the potential to use the NATO web site for configuration 
control. A further issue is whether there should be an XML version, tailored to TG/1's needs. 


The future 


There are ‘Strawmen approaches’ for the above, but these are in an early stage of definition. If the NAAG, 
following the demostration of TG/1's experimental work, determines that it is of relevance, follow-on 
effort would begin to address the aformentioned challenges. 


Clearly, the benefit of TG/1's work will, inevitably, depend on national policy. This may be determined bi- 
laterally, on each coalition operation. It would also require consideration of the level at which tactical 
information interoperability is achieved; again, this would be a bi-lateral decision, which might be at the 
platoon commander level. 


Any NATO movement towards a greater degree of force mixing, particularly during peacekeeping 
operations, may also underpin the need for the STANAG. Policy decisions are awaited with interest! 


The experimental programme has been genuine international collaboration. as engineers of many nations 
are working together. There has been a signicant information flow between national programmes meeting 
one of the other key objectives set by NAAG for Topical Group 1. 
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Abstract 


Multinational coalitions are the standard for land forces in the full spectrum of land war fighting from 
operations other than war to armed conflict. Recent military events have underlined the necessity of 
interaction among the peacekeeping participants, most notably through the channels of liaison. 
Interoperability of the nationals systems, Command and Control (C2) data information exchange, reliability 
of the systems are chiefly the goals for future National Military Architecture. 

The goal of this paper is to describe the opportunity offered to MEADS by the adoption of CORBA (Common 
Object Request Broker Architecture). The intent is not to describe the current MEADS architecture neither 
its future planned development; it simply shows, using MEADS as an example, a possible implementation 
able to underline the advantages that such architecture could provide to a complex Air Defence system. 


1. SUMMARY 


The paper provides a brief introduction on MEADS system, reviews mainly the general concepts of CORBA 
Architecture describing the technical details that realize the interoperability in a heterogeneous 
communication environment, suggesting a possible implementation of CORBA Architecture to an Air 
Defence System such as MEADS underlining the advantages of the approach adopted. 

The last part of the paper describes which kind of analysis has been adopted to estimate the CORBA data 
load budget that characterize the Architecture of the system taken as an example. 


2. MEADS (Medium Extended Air Defence System) 


The MEADS System Architecture consists of hardware and software elements configured in a TDMA 
communications networks that efficiently accomplish real-time Command and Control of total systems 
operations. Figure 1 shows the MEADS System Concept. 

In order to realize Interoperability and Plug and Fight concepts MEADS System will operate in a netted and 
distributed mode. Netted architectures are seamless and self-healing based on the availability and reliability 
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of organic and supporting communications. 
Distributed operations are characterized by physical dispersion of engagement functions or groups of 
functions on the battlefield, wherein data exchanges via broadcast or flood/multi-route patterns may take 


place over extended distances. 
The combination of netted and distributed characteristics reduces the likelihood of a single point failure, 


which disrupts tactical operations. 
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Figure 1: MEADS System Concept 


3. CORBA ARCHITECTURE AND INTEROPERABILITY 


CORBA (Common Object Request Broker Architecture), OMG’s open, vendor-independent architecture and 
infrastructure, specifies a system which provides interoperability between objects in a heterogeneous, 
distributed environment and in a way transparent to the programmer. 

The central component of CORBA is the Object Request Broker (ORB). It encompasses the entire 
communication infrastructure necessary to identify and locate objects, handle connection management and 
deliver data. In general, the ORB is not required to be a single component; it is simply defined by its 
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interfaces. The ORB Core is the most crucial part of the Object Request Broker; it is responsible for 
communication of application requests. 

CORBA applications are composed of objects. An object is an identifiable, fully encapsulated entity that 
provides one or more services that can be requested by a client by means of a well-defined interface (see 
Figure 2) defined in IDL (Interface Definition Language). 

An interface is a description of a set of possible operations that a client may request of an object, through that 
interface. It provides a syntactic description of how a service provided by an object supporting this interface, 
is accessed via this set of operations. Interfaces and object implementation are totally separated. This allows 
having multiple implementations of an object, but still a unique interface. 

An object satisfies an interface if it provides its service through the operations of the interface according to 
the specification of the operations. 


IDL Interface 


Figure 2: Interface vs Implementation 


The basic functionality provided by the ORB consists of passing the requests from clients to the object 
implementations on which they are invoked. In order to make a request the client can communicate with the 
ORB Core through the IDL stub or through the Dynamic Invocation Interface (DI). The stub represents the 
mapping between the language of implementation of the client and the ORB core. Thus the client can be 
written in any language as long as the implementation of the ORB supports this mapping. The ORB Core 
then transfers the request to the object implementation which receives the request as an up-call through either 
an IDL skeleton, or a dynamic skeleton. 

Every object instance has its own unique IOR (Interoperable Object Reference), an identifying electronic 
token. Clients use the IOR to direct their invocations, addressing to the ORB that manages the remote access 
to the objects, the exact instance they want to invoke. 

When the ORB examines the object reference and discovers that the target object is remote, it routes the 
invocation out over the network to the remote object’s ORB using standards protocols called GIOP (General 
Inter-ORB Protocol) and IIOP (Internet Inter-ORB Protocol). 

Figure 3 depicts the data flow in CORBA 
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Figure 3: Data flow in CORBA 


As depicted in Figure 3, any client that wants to invoke an operation on the object must use this IDL 
interface to specify the operation it wants to perform, and to marshal (encapsulated) the arguments that it 
sends. When the invocation reaches the target object, the same interface definition is used to unmarshal the 
arguments so that the object can perform the requested operation with them. The interface definition is used 
to marshal the results for their trip back and to unmarshal them when they reach their destination. 
Correspondences between ISO-OSI and CORBA Client-Server levels architectures are shown in Figure 4 


Application 


Session 


Figure 4: Correspondences between ISO-OSI layers and CORBA Client-Server levels architectures 
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4. DEVELOPING AN AIR DEFENCE SYSTEM NETWORK 
WITH APPLICATIONS IN CORBA 


Many application domains, such as an Air Defence System, require real-time guarantees from the networks, 
operating systems, and middleware components to achieve their quality of service (QoS) requirements. In 
addition to providing end-to-end QoS guarantees and interoperability between each element of the System, 
applications in these domains have to be flexible and reusable. Requirements for flexibility, reusability and 
interoperability motivate the use of object-oriented middleware like the Common Object Request Broker 
Architecture (CORBA). 

The core of CORBA architecture is focused on the concept of layered pluggability where various 
components of the middleware may be “plugged” (included to) or unplugged (removed from) on as-needed 
basis allowing flexible middleware configuration. End-users call and receive data streams (object’s 
operations request and results) from different sources without the need to know the exact location of the 
sources or to have specialized processors to capture the multimedia data. 

For MEADS, as it is depicted in Figure 5, in order to implement the CORBA architecture in a distributed and 
netted network the objects are covered by the elements of the System MEI (Major End Items), Sensors, 
Launchers and TOC and the object’s applications are represented by their functionality (“target tracks”, 
“target identification”, etc.). 


BMC4I Software Structure and Embedding of P&F Modules 


BMC4I S/W 


Application 
(8 domains) 
Sensor/Lnchr 


Objects 
to perform 
tasks ina 


components OSI Application Layer 


(layer #7) Objects 


Object Oriented S/W structure is the platform for P&F integrations 


Figure 5: BMC4I Software structure 
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The configuration network proposed is an hybrid configuration: each element is ready to share its 
applications but always passing through the TOC that represents a client for a fire unit, but could also be seen 
as a server in a Battery or in a wider Integrated Defence System. 

A client (TOC) can invoke an operation to the server object by sending it a Request message. This type of 
message contains all the information that is required to make a remote method invocation. A server object 
(sensors, launchers) responds to a client’s invocation containing the response to the Request. Figure 6 shows 
the hybrid configuration concept described above. 

Adopting the same architecture other “objects” may be in easy way “plugged” to the system realizing 
successfully the concept of the scalability, evolvability, and interoperability. 


Topological Network Configuration 


Figure 6: Hybrid configuration network 


In Corba Architecture, every object instance has its own unique Interoperable Object Reference (IOR), well- 
identified and unique electronic token. The clients, the TOC or other C2 units, use the IOR to direct their 
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invocations, identifying to the ORB (Object Request Broker) that manages the remote access to the objects, 
the exact instance they want to invoke. When the ORB examines the object reference and discovers that the 
target object is remote, it routes the invocation out over the network to the remote object’s ORB using GIOP 
and IIOP. Figure 3 depicts the data flow in CORBA. 

GIOP [5 a protocol that defines an ensemble of messages available between client and server underlining the 
communication syntax between different ORBs. 

GIOP use a standard binary format for the transmission of the IDL type messages, called Common Data 
Representation (CDR) that define the order and the alignment of the Bytes for each IDL message. 

The characteristic of the CDR coding permit a good efficiency in the marshalling technique but the length of 
the messages is not optimum. 

The receiver node sees the messages as a stream of not formatted bit. 

In GIOP protocols are defined eight types of messages whose only two are really important for the flow of 
the messages between client and server: 


- Request: the client sends this kind of message to the server in order to invoke one particular 
operation. 
- Reply: the server sends this kind of message to the client in order to satisfy the invocation. 


The duty of the IIOP protocol is to link GIOP protocol with TCP/IP (mapping), defining all the information 
regarding the address of the objects. 

These informations are included in the IOR of the object, so the IIOP has only to specify in which mode the 
IOR address this kind of information. 

Figure 7 shows the general structure of the CORBA Message. 


Figure 7: Structure of aCORBA message 


5. SIMULATION DATA TOOL 


The data load budget of the netted and distributed Air Defence System architecture under study, has been 
analysed using a NAMEADSMA customized simulation Tool, characterized in input by the Action History 
output file of EADSIM (Extended Air Defence SIMulation) that runs on a predefined and user-selectable 
scenario and the set of CORBA Messages. The type of scenarios used vary from Mass Attack (Many-on- 
Many) to a One-on-One configuration. 

The Tool implements a mapping between EADSIM messages taken from the EADSIM output Action 
History file and the CORBA messages, taken into account the estimated timeline of the System. 

Figure 8 shows the Network data load Simulation tool functionalities and how the various entities involved 
are interfaced each other. 
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Figure 8: Network Data load Simulation tool 


This simulation tool allows the operator to select, through a user-friendly interface, the data bit-rate, the 
Sensor tracking frequency and in a future version it will also incorporate the possibility to compare directly a 
TDMA implementation with the features of a CDMA one. 

Figure 9 and 10 show the result of the simulation data tool: as a result of running the simulation tool the 
network data load of the system under analysis is shown in figure 9 detailing the load of the single MEI 
while chart in figure 10 details the load of the whole system in percentage as a function of time. 
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Figure 9: Network Data load Figure 10: % Time load as a function of time (sec) 


One of the possible applications of this Simulation tool is to analyse and establish the interoperability degree 
between two different Air Defence systems, between single components (MEI) of different Weapons 
Systems characterizing them as distributed application shared on the same CORBA network. 
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ABSTRACT 


To be able to model systems for C2 we have to evaluate and find appropriate methodology for modelling 
and representation of our knowledge about military organisations and military behaviour. Military 
organisation and military behaviour are important parts of C2. 


In this paper we present a study of modelling military organisation and military behaviour in a generic 
manner, using two different knowledge representation techniques: the Unified Modeling Language 
(UML) and Bayesian Networks. The class diagram that is provided by UML is well suited for 
representing military organisations whose structure is well-known, since military units and their 
interrelations can be represented as classes and interrelations between the classes. On the other hand, it 
is a much harder task to represent military organisations that are not well-known or military behaviour 
because of the uncertainty associated with them. Different behaviours are triggered in different 
environments using different doctrines, and the outcomes of the behaviours are uncertain. Due to 
complexity, time constraints and war friction, causal relations between different factors, which play an 
important role in warfare, may be uncertain. 


Bayesian Networks seems to be a reasonable choice for representing uncertain military behaviour as 
well as uncertain military organizations, since this method combines uncertainty and a priori knowledge 
in a homogeneous way. We can compare those models and facilitate the verifying process. As result we 
get a more reliable BN and the modelling time decreases. 


1.0 INTRODUCTION 


Our intention with this paper is to highlight the need of interaction between two different modelling 
techniques, Unified Modelling Language (UML) and Bayesian Networks (BN). Despite the fact that 
these techniques are very different and are used for different purposes, we propose an approach generic 
UML modelling of military organisation and military behaviour as a first step towards modelling with 
BN. Modelling with BN involves nets with high complexity and a structured overview is required. UML 
class diagrams enable a good visual overview of class structure and relations between different classes. 
Having a UML structure in the “background” makes it easier for us to implement large BN networks. 
Finally we can compare those models and facilitate the verification process. As result we get more 
reliable BN models and modelling time decreases. 


Military organisation and behaviour are described in military doctrines. The first issue is how to model 
doctrines on a conceptual level and the second issue is how to implement these concepts in a concrete 
model. The connection between the conceptual level and a concrete model is also discussed in this paper. 
Modelling on the conceptual level has been performed by using textual and graphical documentation 
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techniques associated with the Unified Modelling Language (UML) and Bayesian Networks (BN), 
respectively. Implementation of the model was performed in MATLAB. The implementation is a BN 
model which uses some of the classes and variables represented by a UML model. 


In this paper we will represent a doctrine class diagram in UML with focus on ground forces, as well in a 
BN model, and finally discuss UML and BN as modelling techniques. The BN model that we have 
implemented represents a relatively small part of the UML doctrine model. The UML model can be used 
for more general purposes while the BN model is used to model the behaviour of a relatively small 
hostile force unit that acts in a certain environment. 


The importance of developing generic models in command and control (C2) is increasing due to issues of 
co-ordination, co-operation, training, decision support etc. When modelling warfare a plethora of factors 
has to be considered. In such complex problems the increasing need for classification of knowledge 
arises. We found it important to perform such a classification in a generic manner. The class models 
could then be reused with some modification and should be easy to update. Consequently, the modeling 
expert can concentrate on one part of the model at time. E. g., one generic model of a military 
organisation and military behaviour can be reused for modelling different doctrines and for different 
purposes by using a well-known modelling technique. Consequently, we have performed a UML 
classification of doctrines in a generic manner. BN are able to represent uncertainty that arises when 
modelling doctrines, e. g. fog of war, especially when modelling enemy organisation and military 
behaviour. 


2.0 MODELLING TECHNIQUES 
2.1 Unified Modelling Language 


In this work, we use two different modelling techniques. The first one is the Unified Modelling 
Language (UML, see [1]). UML is a set of graphical description techniques for specifying, visualising, 
implementing and documenting object-oriented systems [2]. The aspect of the Unified Modelling 
Language (UML) that has been used in this paper is the class diagram. We have not performed sequence 
diagram representation in UML because of the tremendous complexity of the military operations 
considered here. 


The class diagram in UML provides graphical representation of object types, also called classes. The 
model describes relations between classes in a uniform way by using a standardised representation. A 
class is a template containing mutual properties of a group of objects. Types of the objects, classes, may 
be everything from physical objects, e.g. tank, to abstract objects such as plan and task. A more general 
definition of the class concept is that the class is a set of objects with the same behaviour which are of the 
same type. “Object-oriented methods also provide means to increase reuse of design efforts, including 
the concepts of patterns and the generalization/inheritance relation. These means offer the possibility to 
describe problems and to model properties of objects in a generic fashion, considering only common 
features before instantiation for the specific case” [3]. 


When we want to describe a class model in UML we first identify interesting classes and after 
performing that step we describe relations between them. Consequently, we make a generic structure that 
can be used for implementation for different purposes. 


The first step towards a UML modeling was to collect knowledge about military organisation and 
military behaviour. Most of this knowledge has been collected from doctrine manuals. In our model we 
use a representation of Swedish doctrines, although in generic manner. By using this kind of modelling 
approach, the UML structure can be reused/generalised to model other regular military organisations 
with some modifications. 
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Doctrines provide hints about how military tasks should be carried out. This means that some of the 
military behaviours can be classified. Given information about environment, force balance, opponent’s 
position and other rules that have influence on military behaviour we can say that some behaviours are 
more probable to occur in some situations. UML has a very good expressive power for classification. 
Class diagrams in UML give very good overview but we cannot say anything about the probability that a 
given class, in this case a class describing a particular behaviour, will occur. E. g. we found it difficult to 
express how using UML a class representing frontal attack behaviour of some hostile military unit is 
likely to occur given the information that we are close to the enemy and the fact that visibility is good. In 
some cases certain classes are irrelevant and in other cases they are important. 


Relations between attributes of different classes cannot be represented in UML class diagrams. Instead, 
ina UML class diagram we specify relations between different classes. 

On the other hand, the advantage is that the principle of encapsulation makes it possible to build 
implementations that have parts which are more autonomous, objects in UML. 

In BN instead of attributes we have variables. We see the attribute as a generalisation class of class 
variable in UML. 
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Figure 1: UML model of a platoon 


The model in Figure 1 is developed and improved from an even more generic model of C2, see [3]. The 
interpretation of the figure above is that one Platoon consists of three or four Groups, one Platoon 
Commander and one Deputy Commander. The Platoon has an attribute Formation with four possible 
values: Lead, Battle Line, Stepped Formation and Battle Triangle. This variable, attribute in UML, 
will be represented in BN with these values. Platoon is an Organisation. The subset of Physical 
Resource class is a class of Technical Artefact which contains attributes that correspond to the technical 
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equipment of the platoon in this case. As we see in this class diagram we do not have any description of 
relations between attributes. 


When modelling a hostile military organisation we do not always have complete information about it. E. 
g. we may not know how many tanks an enemy tank platoon consists of. Let us say that in other cases 
hostile platoon consists of three or four tanks, in some cases there are also some other vehicles in a 
platoon. In UML we can express this relation as “the platoon consists of three to four groups”. A 
statistical interpretation of that statement may be the uniform distribution over the number of groups. 
That implies that the hypotheses three and four groups are equally probable. There is no convenient way 
in UML to express for example our knowledge that four groups is more frequent than three groups. A 
deficiency of the UML is its inability to represent uncertainty in a comprehensive way. 


2.2 UML doctrine model 


In Figure 1 we showed the model of a platoon. In the same manner Figure 2 shows a company model. 
This model also represents the relation between company class and platoon class hence obtaining a 
hierarchical representation. 
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- Formation: 
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Command 
platoon 


Formation: 


Figure 2: Company description with UML 


It is not enough when modelling military doctrines to describe relations between different units, their 
roles, which resources are they part of, and which resources are put to their disposal. Military behaviour 
is however an important part of doctrines that is not part of the model. In concrete situations there is a list 
of the military behaviours/actions to be executed. In Figure 3 we show a model in which relations 
between military behaviour as a part of planning, military organisation and environment are represented. 
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Figure 3: Planning, doctrine and environment 


We recognise this kind of problem in AI as the agent planning problem under uncertainty; see [4]. As we 
see in Figure 3, environment rules and doctrine rules are subsets of more general rules in an agent 
planning problem. Utility-based rules represent all rules that are not described in manuals but are 
frequently used. Some military or paramilitary organisations, for instance, lack doctrine rules. Plan and 
task are assigned to the role which can be for example a commander of a military unit or tank driver. In 
order to solve the task and execute the plan a role has to use resources. The role can be part of a larger 
plan and be subordinated to a resource, e.g. platoon member is subordinate to platoon. 


Part of the model is also the environment, which plays an important role when making plans. It is 
regarded by military commanders both as opportunity and as restriction to execution of their plans. 
Information about the opponent is also important when making own plans. However representation of 
some “generic” opponent is not performed in our UML diagrams, although it was modelled with our BN 
model of a particular hostile tank company. 


2.3 Bayesian Networks 


In general when modelling warfare we have to deal with uncertainties. Prediction, fusion of the uncertain 
information, war friction, enemy courses of action etc., are examples of where a high degree of 
uncertainty is involved. 


Bayesian Networks is a statistical modelling method used to represent uncertain causal relations between 
different statistical variables. 
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The graphical representation of BN, is different from that of UML and uses nodes and arcs 
representation. Only one kind of relation between variables 15 described. This kind of relation is also 
called “influence relation” hence BN is also subset of influence diagrams. 


Each node represents a variable that can be either discrete or continuous. Variables and its states are 
represented by conditional probability distributions also called subjective probabilities. BN is also 
denoted belief network since they describe our belief about the state of the variables. 


When new evidence arrives, the probability density function over each variable’s states change and new 
belief propagates through the network weighted by our subjective probabilities. An advantage of the BN 
is that our knowledge is implemented in a fragmented manner. We only have to “explain” how a 
particular node depends on its parents. E. g. in Figure 4 we define the probability density function of the 
variable WetGrass. The variables that make direct influence on the variable are called parents. WetGrass 
in this example has parents Sprinkler and Rain. The a priori probability density function of variable 
WetGrass does not model influence of the variable Cloudy. However, let us say that new evidence 
arrives. The statement of the new evidence is that we know that the weather is cloudy, Cloudy = True, 
this evidence will propagate through the network and make influence on our belief about if grass is wet 
or not. The process where weighing the new evidence with our subjective, a priori, knowledge is 
performed is denoted statistical inference. 
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Figure 4: An Example BN [5] 


When using BN we can infer evidence in all directions by using the Bayes rule. E. g. we can answer the 
question what is the probability that the sprinkler was on if we perceive that the grass is wet. The causal 
relations give only a description of the model. 
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According to [6] the formal definition of BN is: 
¢ A set of variables and set of directed edges 
¢ Each variable has a finite set of mutually exclusive states 
¢ The variables together with the directed edges form directed acyclic graph (DAG) 
¢ ΤῸ each variable A with parents B1 .. Bn there is attached conditional probability table P(A| B1 .. 
Bn) 


Mathematically expressed: 


P(X1..Xn) = shee | par(Xi)) 


i=l 
Where πὶ is the number of the nodes in the network and X;represents a stochastic variable no. i of the BN. 


When we describe a time-dependent BN we speak about Dynamic Bayesian Networks (DBN). It consists 
of several layers of BN with the same structure. The additional influences in DBN are the variables of the 
previous step(s) that make influence in variables for future step(s). Note that the term “dynamic” means 
that we are modelling a dynamic system, not that the network changes over time [7]. The variable values 
changes over time but the network topology remains same. 


The problem of how to handle complexity arises when we want to describe behaviour of many military 
units instead of one military unit. The BN becomes very large with many state variables. When we model 
a clear conception of how the system works is required. As the number of variables grows, the difficulty 
of envisioning such a model increases enormously [8]. Therefore the process of classification and 
describing relations between classes is required. 


The important issue is how to build a BN from the UML class diagram. As a first step we create a BN 
representing a military unit, a platoon in this case. The hostile platoon’s behaviour depends on factors 
like environment, platoon doctrines and superior unit behaviour, a hostile company in this case. When 
we implement the BN we realised that we cannot use the principle of reuse/generalisation more than 
copy and paste of the BN fragments. In this particular example we realised that we had to copy the BN 
representing platoon three times. The drawback of this BN is, beside the fact that we had to manually 
rename variables for platoon two and three, that when we wanted to change a structure of the platoon 
representation we had to change each platoon fragment. The structure of the UML military unit and 
planning model facilitated the work of modelling (D)BN representing a hostile company but no 
formalism has yet been applied. 


2.4 A Hostile Company Bayesian Network Model Example 


In this section we describe a particular BN model that is used for recognition of enemy plans. 
On-line multi-agent stochastic policy recognition aims to detect which policies an agent or group of 
agents are executing by observing the agents’ actions and by using a priori knowledge about the agents in 
a noisy environment. The method chosen for the representation of this task is Bayesian inference using 
dynamic Bayesian nets. The inference is intended to derive belief measures for enemy plans. 


In military applications the issue is how to recognise certain military behaviours of the enemy. Using the 
movement pattern, speed, distance, visibility, maneuverability distance to presumptive target etc., it 
might be possible to fuse the acquired knowledge about the enemy and use it in policy recognition. The 
advantage would be that military commanders, having better knowledge about the enemy’s intentions, 
will be able to act earlier. The ability to act preventively increases as well. 


The purpose of the network is to make qualified estimation of the opponent’s behaviour based on 
observations, knowledge about opponent’s doctrines as well as data from the terrain. 
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As the first step in making a company BN, we make a BN of a single hostile platoon. We specify 
variables in the graphical diagram. After that, the causal relationships between variables are specified. 
Finally, we define conditional probabilities to “explain” how a certain variable’s values depends on its 
parents values. E. g. we previously mentioned variable Formation, see section 2. 1, that may have 
following values: Lead, Battle line, Stepped Formation and Battle Triangle. We define a conditional 
probability distribution over all possible combinations of values. In Figure 5 we see the node 
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Figure 5: Planning, doctrine and environment 
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Formation has following parents: platoon manoeuvrability, platoon policy and cover. By defining our 
probability distributions we model our a priori knowledge. E. g. the formation battle line is less probable 
to be used by the hostile formation when the manoeuvrability is bad. The formation battle triangle is 
more probable to occur in this case if the variable of platoon policy is attack. The variables formation, 
distance to presumptive target, and direction of guns are used to connect observations to different 
policies. We denote these nodes doctrinal nodes. 


After building a platoon model we define a company model that consists of three platoons. In this case 
we intended to define a platoon class with three instances. But modelling with classical BN does not 
support this kind of approach. Instead we had to perform a cut and paste process and when we wanted to 
change the model of a platoon we had to change it in all the three instances. 


The second drawback of the BN was that connection between platoon and company model is only via 
variables. The principle of encapsulation does not exist in classical BN. One of the problems is that 
fragmentation of the BN could violate laws of the statistical inference. 


The hostile company BN model was implemented in MATLAB. It takes environment, doctrines and new 
information about enemy forces movement into account. We are able by using this model to observe the 
most probable policies that the enemy is executing on different abstraction levels. 


3.0 DISCUSSION AND CONCLUSIONS 


The UML and BN are two different modelling methods for different purposes and for different modelling 
approaches. Nevertheless we propose a modelling approach that combines knowledge incorporated in 
UML-class diagrams when modelling BN. The reason is that when using a generic well defined structure 
the process of modelling large and complex BN is facilitated. 


In order to facilitate future modelling process, the concept of Object-Oriented Bayesian Networks 
(OOBN) should be studied. Especially this concept could be useful when modelling large military 
formations with (OO)BN. This principle of modular and reusable representation of a BN, OOBN, has 
been applied in a probabilistic representation language (SPOOK); see [8]. 


Some parts of programming code of OO-languages as Java and C++ can be generated directly from 
UML. Is it possible to develop a formalism that generates at least some parts of a BN from UML in 
similar manner? There are many obstacles to achieve that. One of them is the difficulty of UML to 
handle uncertainty in a uniform way. A uniform notation to express uncertainty in an easy and 
comprehensive manner should be developed for UML. 


Also the inconsequent fragmentation of BN in classes could violate rules of statistical inference. 
However, we are convinced that a new kind of approach of designing BN is required to achieve better 
compatibility with OO-methods. 
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ABSTRACT 


The need of information on tactical battlefield will increase in future battles. Not only to gain information 
on battlefield, but also to convey it where it is needed on time, will be very important. The next generation 
mobile tactical communications systems will provide a robust, reliable, secure and flexible network to the 
mobile users of tactical battlefield. However, it is a question under interest to predict the impacts of 
different battle conditions on their performance. We conducted a simulation study of a messaging system 
of a model brigade which mobile users use TDMA (Time Division Multiple Access) radios and TDMA 
technique for channel access. We identify a set of components, which are called Mobile Subscriber 
Terminals, Personal Subscriber Terminals and Radio Access Points that make up mobile wireless 
network. The mobile wireless network can provide networking facilities and many simultaneous voice and 
data connections to the mobile users. The focus of this study is to construct a simulation model of a 
messaging system of a model brigade on tactical battlefield and to determine if the system is capable of 
supporting the data exchange in performance criteria under different conditions. The simulation is 
performed by using Arena 7.0 simulation program and results are analysed by using SPSS statistical 
package program. 

Keywords: Simulation, messaging system, mobile wireless network 


1. INTRODUCTION 


The success of military operations on today’s tactical battlefield is closely related to the C4I (Command, 
Control, Communications, Computer and Intelligence) concept. Gathering, exploiting, and protecting 
information is critical from the view of C4I concept. To achieve the C4I functions the existence of a 
secure, robust, reliable and mobile communications infrastructure is very important. This infrastructure 
should be capable of conveying messages, data, imagery, and video files as well as voice communications 
among the fixed and mobile components of the battle forces in a secure, and timely manner. 


Advances in technology affect the way that the warfare is conducted. Recent improvements in 
information, computers and communications technology such as broadband networks, digital cellular 
systems, wireless computer networks, evolving computer systems, global positioning and other 
technologies opened new horizons in the communications systems. Electronic mail, cellular telephone for 
voice and data, vehicle position reporting/tracking systems, and many other products have appeared. With 
these evolving technologies, today, the efforts to reach the goal of “digitizing the battlefield” increased. 
The intelligence about the battlefield such as the strength and placement of the enemy, the geographical 
positions of friendly troops are tracked and analyzed with computers and, again these computers can be 
used to pass the information between components of the battlefield. These improvements provide future 
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war fighters and decision makers with accurate information in a timely manner. 


In our study, we develop a simulation model of the messaging system of a model brigade on the 
battlefield. In the messaging system, information in forms of messages, reports and plans are 
accomplished with personal computers. GPS information is automatically updated, giving subordinate 
units complete knowledge of the friendly situation; thus a common view of the battlefield. The multimedia 
(video, imagery) is one of the most important parts of this information. The users of the system are mobile 
and use Time Division Multiple Access (TDMA) radios to send this data. We examine the behavior of the 
messaging system to determine if it is capable of supporting the needs of the users in the battlefield. We 
also investigate the significant factors that affect the system performance and their relationships. Finally, 
we evaluate the system under different types of operations. The objectives of this study are to; 


¢ develop a simulation model of a brigade messaging system, 


* examine the behavior of the communication system to determine if it is capable of supporting the 
messaging needs under different conditions for various performance measures, 


* analyze the effects of the model parameters on the performance, 
¢ — establish the nature of the relationships among input factors and system responses, 


* compare system responses under different circumstances. 


The outline of the paper is as follows: In Section 2, the system is briefly described. In Section 3, the 
simulation model is explained in details and validation and verification of the model is discussed. The 
results of the output analysis and experimental design are presented in Section 4. Finally concluding 
remarks are given in Section 5. 


2. THE SYSTEM DESCRIPTION 


In the brigade structure that we model, there are a Brigade Headquarters, a Communications Company, an 
Antitank Company, an Engineer Company, an Air Defense Battery, an Artillery Battalion, two 
Mechanized Infantry Battalions, and two Armor Battalions. All units in the brigade messaging system use 
mobile subscriber terminals (MST) or personal subscriber terminal (PST). A MST is a terminal, which is 
used for both voice and data communications. It is generally mounted on a vehicle. Also, it may be 
connected to a computer to send data, multimedia or imagery. MSTs transmission range is maximum 10 
km in the line of sight (LOS). A PST is a terminal, which has the same features with MST except output 
power, transmission range and dimensions. Its transmission range is maximum 2 km in the line of sight. A 
Radio Access Point (RAP) is the gateway from LAS network to the WAS backbone. Units reach the 
subscribers of other networks via RAP. Units use TDMA scheme to access the channel. Units using the 
same frequency band can communicate with units that are in theirs transmission ranges and can form a 
radio network automatically in the tactical field. Also, units can act as a relay to the voice or data 
connections of other units without interrupting communication services to its own user. For voice calls and 
data connections, a maximum of 3 and 5 hops are available respectively, while real-time video 
transmission is only available for the destinations in the transmission range. Units contain internal GPS 
receivers and obtain position location information from the GPS system. The GPS information is 
automatically distributed in the network. 


There are many types of data including voice over radio, orders, operations plans, reports, maps, real-time 
video files, etc. that the users will exchange in the system. However, we classify these data into four 
groups as voice calls, messages, real-time video, and other data files. The transmission speeds to send 
these data are 4.8 Kbps, 9.6 Kbps, 64 Kbps, and 9.6 Kbps and the needed number of channels to realize 
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the transmission are 2, 4, 24, and 4 respectively. 


We use a distributed asynchronous version of Bellman-Ford algorithm, which is in the class of table- 
driven routing protocols in our study. In this protocol, each user holds a routing table containing the length 
of the shortest path to the every destination in the network. An update packet is broadcasted by a node 
when a topological change is detected. This packet consists of only changing nodes. Every node updates 
its routing table according to this information. When an update packet is received from a neighbor node, 
an acknowledgement of the update packet is sent to the neighbor node. This process will be repeated until 
all the nodes have updated their routing tables. Also, each node broadcasts its routing table periodically. 
The update data is kept for a while to wait for the arrival of the best route. 


We use distributed time slot assignment protocol (DTSAP) [1,2] for channel access. DTSAP is in the class 
of conflict-free, dynamic allocation, reservation based, multiple access protocols. In this protocol, every 
unit has its own control channel, which is designated by RAP. In control channel the unit broadcasts its 
position information and call related information to the network. A frame consists of 28 data channels. 
Using DTSAP, transmission of data or making a voice call occurs in a two-stage procedure. In the first 
stage, a connection between source and destination node is established and in the second stage data is 
transmitted through the route or voice call is made. When a node wants to make a connection with 
destination node, it first sends a connection request packet to the destination node if it is in transmission 
range, or to the next hop in the route to the destination if it can be reachable in allowed number of hops. 
This call request packet involves the address of the destination node, number of the channel needed and 
the data channels that the node cannot broadcast and receive. Upon receipt of connection request packet, 
the relay unit selects the channels for transmission under following constraints: 


¢ The source node and relay unit cannot broadcast or receive from the data channels dedicated for 
other transmissions. 


¢ The source node cannot broadcast from the data channels that its neighbors receive and the 
neighbors of relay unit broadcast. 


¢ The source node cannot receive from the data channels that its neighbors broadcast. 


¢ The relay unit cannot broadcast from the data channels that its neighbors receive and the 
neighbors of the source node broadcast. 


¢ The relay unit cannot receive from the data channels that its neighbors broadcast. 


If the channels are available, it sends a connection confirmation packet that includes the selected data 
channels. Otherwise, the connection request is rejected. Ifthe relay unit is not the destination, it starts the 
next leg of the connection towards the destination node. After a connection is established, the destination 
node sends a call-accepted packet back to the source using data channels. After the call accepted packet is 
received, the source node starts transmission of data. The communications between source and destination 
node is full duplex which means the source and destination node can send data to each other 
simultaneously. At the end of every packet the destination node, if it has successfully received the packet, 
will return an ACK (acknowledgement) packet to the source node. The source node will retransmit the 
packet if it had not received an ACK packet after a defined period. When a node detects a new neighbor 
during transmission, it sends a resolve conflict packet, its time slot assignment table and its routing table 
to the new neighbor. The neighbor terminates all connections that have a conflict and it broadcasts its 
revised routing and time slot assignment tables in its control channel. All nodes update their routing tables 
according to new topology. After all data transmitted or if a node determines that it has no longer 
connected to a node in the route, to terminate the connection, source node sends a clear request packet in 
the data channel. Upon receipt of clear request, the destination node and the nodes on the route sends a 
clear confirmation packet from their control channels consecutively, and the neighbors update their tables. 
This completes the data transmission. 


RTO-MP-MSG-022 15-3 


The Modelling and Simulation of a Messaging System of a Model Brigade ORGANIEATION 


3. SIMULATION MODEL 


It is always desirable to obtain answers to the questions by analytical solutions. But, because of the 
complex nature of the system and dynamic/stochastic elements, simulation model is used to model and 
analyze the system. First of all, the tactical communication system under consideration has many 
stochastic elements such as, the call arrival rates varies for each user, the destruction of users may occur at 
an unknown time, the available channel capacities differs according to the geographical position of users. 
There are many analytical studies for queuing systems of communication networks. But the systems are 
mostly continuous and the state variables change continuously over time. Thus, the mathematical 
procedures of these analytical solutions are very complex for our network. Only steady-state results are 
possible for these systems. Also, it is very difficult to obtain estimates of parameters other than mean 
values. Because of economic reasons and difficulties creating real world conditions, it is almost 
impossible to exercise the systems in the field, either. Thus, to answer a wide variety of “what if” 
questions is a major issue. Simulation enables us to analyze different policies and system alternatives in 
our study. Simulation can also quantify the difference between the alternative systems and helps to see 
their advantages or disadvantages. 


3.1. Model Development 


To build the model we first observe the system and the interactions among its various components and 
collect data on its behavior. Then we construct a conceptual model (a collection of assumptions on the 
components and the structure of the system, plus hypotheses on the values of model input parameters) by 
carefully determining the level of details. After all, we translate the operational model into the 
computerized model. The stages of the model development process are given in Figurel. 


REAL 
WORLD 
SYSTEM 


CONCEPTUAL LOGICAL SIMULATION 
SYSTEM MODEL MODEL MODEL 


Figure 1. The stages of model development process 


When developing a simulation model, determining the correct level of detail for the model is very 
important. The simulation model should have enough details to represent the real world system. There is 
always a trade off between accuracy and cost of the model and level of details. Lack of details usually 
causes wrong answers to the questions, while, too much detail requires more time and efforts, longer 
simulation runs, and it is more likely to make errors. Also, it is more difficult to debug and make changes. 


3.1.1. Conceptual Model 


Conceptualizing a model is one of the important phases of model development. A conceptual model 
provides an organized way for an analyst to document the system of interest. We create conceptual models 
of these real world systems to examine the essential components and structures of the real world systems 
under consideration. Then the basic elements of this simulation model are determined by the certain 
characteristics, components and the structure of the assumed system. During conceptualization, we gather 
data about the systems, and then we construct the logical model (flowchart) to show relationships among 
the elements of the model. Conceptual model contains elements of the real system, which should be 
included in our model. These include events, entities, attributes, exogenous variables, endogenous 
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variables, operational rules, initial conditions and assumptions of the system. The basic elements of the 
proposed simulation model is given below: 


Entities. An entity is an object of an interest in the system, which requires an explicit representation in the 
system. In our system, entities are voice calls, messages, live video files and other data files. 


Attributes. Attributes are the characteristics of an entity. Our attributes are source node, destination node, 
source RAP, destination RAP, maximum hop number and call duration. 


Events. An event is an instantaneous occurrence that changes the state of the system. The events of the 
system are destruction of nodes, call request, call establishment and clear request. 


Activities. An activity is a time period in which the state of an entity does not change. The activities of the 
system are call establishment and data transmission. 


Input Variables. Input variables are number of MSTs, number of PSTs, number of RAPs, velocity of 
nodes, direction of nodes, weather and terrain conditions, call duration. 


State Variables. State variables of the system are state of MSTs, state of PSTs and state of RAPs. 


Performance Measures. Performance measures include following: Number of rejected calls because of 
insufficient data channels, number of rejected calls because of unreachable destinations, number of 
terminated calls because of unreachable destinations, total number of calls, ratio of Terminated Calls, 
average message delivery time, average call establishment time, unit utilization, channel utilization, ratio 
of unreachable destinations (ROUD: the ratio of number of the calls rejected since the destination is not in 
the coverage area of allowed number of relay units over total number of calls) and ratio of blocked calls 
(ROBC: the ratio of number of rejected calls because of insufficient radio resources over total number of 
calls). The last two performance measures are important, since as these ratios get higher, the users of the 
system will have difficulties to establish a communication link with the destination nodes, even in some 
cases they cannot communicate with some of them. 


We have also made some assumptions in the model. These are: 
¢ All units are synchronized in time. 
¢ Every unit has a unique identification number, which is known by other units. 
¢ All links are bi-directional. 


¢ Units detect the existence of a neighbor or a link failure within a finite time by a link layer 
protocol. 


* Velocity of a unit is uniformly distributed between 0 and 8 kilometers per hour. 
¢ Units cannot go out of the region defined for every hour of simulation. 


* The lost packets over a link are transmitted and received again by a link layer protocol, so that 
transmission is completed in the call duration time. 


* Packets sent in control channels are received correctly by the neighbor units in transmission range 
of the source node. 


¢ There is no electronic attack measure of the enemy. 
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3.1.2. Logical Model 


Logical model shows the relationships among the elements of the model. We construct the logical model 
of the messaging system of a brigade via flowcharts. A flowchart is a pictorial summary of the flows and 
decisions that comprise a process. It has several advantages in constructing the model such as functioning 
as a communication and planning tool, providing an overview of the system, defining roles, demonstrating 
interrelationships and promoting logical accuracy. 


3.1.3. Simulation Model 


We write the code of simulation model by using the Arena 7.0 simulation program [3]. There are many 
simulation packages that are used for modeling communications networks. Arena software is a general- 
purpose simulation language, that is, it can also be used for modeling manufacturing systems, for combat 
modeling or for modeling communications networks. It is also a powerful and flexible tool in creating 
animated models and offers reasonably good simulation output process. The major advantage of general- 
purpose languages is their ability to model almost any kind of communications network, regardless of its 
complexity. Their possible drawbacks, as compared to some simulators, are the need for programming 
expertise and possibly the long time spent coding and debugging that is associated with modeling complex 
networks [7]. Hence, to develop the model was a challenging task during our study. 


3.2. Input Data Analysis 


The communication system that we model is a new system and it is not tried in a war condition or in an 
exercise that we know. Hence, it is not possible to collect required input data for our system. But, in a data 
network, it seems reasonable to assume that the arrival process can be described as a Poisson process. 
Thus, we use exponential distribution for the call interarrival times. For the call duration times, we used 
uniform distribution, since it provides a good approximation when it is known that the service time is 
random, but no information is available about the distribution [4]. We obtain the parameters of the 
distribution functions by interviewing the military experts. Some of the data points are taken from the 
army field manuals that are written according to the war experiences. In the future applications, as we 
gather new data sets, the input data analysis techniques discussed in Law and Kelton [5] can be employed 
to find correct distribution functions for random variables. 


3.3. Model Verification and Validation 


Verification and validation is one of the most important stages of a simulation study, since any 
conclusions derived from the model will not have any meaning unless the model verified and validated. 
We verify and validate our model by using the following techniques and considering the principles of 
Balci [6] for all steps of our study. 


3.3.1. Verification of Model 


Model verification is the process of determining that a model implementation accurately represents the 
developer’s conceptual description and specifications. In other words, by using verification techniques we 
will check the translation of the conceptual model into a correctly working program. We use the tools such 
as tracking, debugging and animation to verify the model. 


3.3.2. Validation of Model 


Model validation is the process of determining the degree to which a model is an accurate representation 
of the real world from the perspective of the intended uses of the model [8]. In validation process, we 
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would like to see that the proposed model for our system is really the accurate representation of the real 
system. Only after the model is validated the evaluations made with the model can be credible and correct. 
We use the techniques such as sensitivity analysis, face validity and fault/failure insertion test to validate 
our model. The results are presented in Table 1. As expected the model produced invalid behaviours for 
both cases. 


Table 1. Results of fault/failure insertion test 


Performance Values for Values for Fault | Values for Failure 
Measures | Typical Model | Insertion Test Insertion Test 


0.0074 0.0011 0.082 
0.0106 0.025 0.379 


4. DESIGN AND ANALYSIS OF EXPERIMENTS 


In this section, we model messaging system of a model brigade in an attack operation. We first determine 
number of replications needed to achieve a desired accuracy in simulation experiments. Then we measure 
the system performance and finally implement factorial design to explore the significant factors and their 
effects. We begin the statistical procedures by determining number of replications needed to achieve a 
desired accuracy on the estimates of the performance measures. We use sequential procedure with relative 
precision criterion to determine number of replications [5]. The specific objective of the procedure is 
obtain an estimate of » with a relative error of y (0<y<1) and a confidence interval of 100(1-a) percent. 
The two-stage procedure is as follows: 


Step 1. Make no replications (more than two) of the simulation and set n = no 


ΞΞΝ S? 
Step 2. Compute X (71) and d(n,@) where, d(n,a@) Ξε ἔς να, 2) is the half-length of the confidence 
interval. 
O(n,a) _ = : : . bard : 
Step 3. If Dx | <y, use X(n)as the point estimate of and stop. This ratio is an estimate of the 
X(n) 


actual relative error. y = 


is the adjusted relative error to get an actual relative error of vy .Else make 
24 
one more replication and go to Step 2. 


The two main performance measures that we will evaluate are ROBC and ROUD. We choose the initial 


sample size as 10 and y= 0.10 for both of the performance measures and simulate the system for one day 
length. The averages and variances for each performance measure are presented in Table 2. 


Table 2. The averages and variances for each performance measure 


Performance ROBC ROUD 
Measure 
X(n) 0.0106 0.0074 
S?*(n) 3.32 E-06 1.59 E-06 


We find that we need to make at least 10 replications for ROBC and 12 replications for ROUD to achieve 
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the desired accuracy. Then we decide to make 15 replications of simulation model. After determining the 
number of replications to achieve the desired accuracy we construct the confidence intervals for ROBC 
and ROUD. In our case a =0.05. 


4.1. Evaluation of System Performance 
To evaluate the system performance, we conduct 15 simulation runs, and analyse the results. The values of 


average of 15 runs for different various measures are given in Table 3. 


Table 3. Results of average of 15 runs for performance measures 


Performance Measure Average 
Total number of calls 3215.7 
Number of blocked calls 34.2 
Number of blocked messages 15.67 
Number of blocked voice calls 3.46 
Number of blocked video transmission 9.13 
Number of blocked other data 5.93 
Number of unreachable destinations 23.9 
Number of terminated calls 0.67 
Average call establishment time 1.91 sec. 
Average call duration time 47.71 sec. 


When we evaluate the system performance, it seems that the system does not have a serious problem. 
Approximately one percent of calls are blocked because of insufficient resources that are an acceptable 
value for a communications network on the battlefield. Also, the value of ratio of unreachable destinations 
is evaluated as in good standards. While investigating the results of simulation runs, we see that the 
system is significantly affected by live video transmission. The plot of ratio of blocked calls by data types 
is presented in Figure 2. 


0.1 


Messages Voice calls Live video Other data files 
transmission 


Figure 2. ROBC values for different types of data 


Since, live video transmission needs an important part of resources (24 data channels), over nine percent 
of live video transmission is blocked. Voice calls have the smallest ROBC value since this type of data use 
only two channels of system resources. Since live video transmission has the greatest ROBC value, we 
examine the system performance in the absence of live video transmission to see the effect of this type of 
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data on performance measures. We see that all the messages are sent to their destinations without any type 
of blocking in the absence of live video transmission. We also investigate ROBC values for different types 
of units. The results of ROBC values by types of units are presented in Figure 3. 
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Figure 3. ROBC values for different types of units 


The reconnaissance squad has the greatest value of ROBC. The second greatest value belongs to 
mechanized infantry and armor companies. In the system, only these units transmit live video. The 
mechanized infantry and armor battalions are the third in terms of value of ROBC since they realize the 
greatest data transmission in the system. 


4.3 2" Factorial Design 


To study the effects of the factors on performance measures and the interactions between factors, we use 
factorial design. A special type of factorial design is 2‘ factorial design, which is widely used in 
experiments involving several factors. We implement 2‘ factorial design for the model to determine the 
effects and possible interactions of factors on system performance considering performance measures. In 
our study, there are five factors under consideration. An explanation of factors and their levels is given 
below. 


Factor A: In the existing system, the brigade has five mechanized infantry battalions and two armored 
battalions. We determine the high level as a typical brigade organization. To examine the effects of 
different number of users on the performance measures, we decrease the number of users in RAP-2 and 
RAP-3 by removing a mechanized infantry battalion from RAP-2 and an armored battalion from RAP-3 as 
the low level of factor. 

Factor B: At high level of Factor B, we increment the arrival rates messages twice of typical conditions. 
Low level represents normal conditions. 

Factor C: At the low level of the factor, the units move at a speed of 4 kph and the brigade moves 24 
kilometres per day. At the high level, mobility is high. Units move at a speed of 16 kph, and the brigade 
moves 72 kilometres per day. 

Factor D: In bad weather and terrain conditions, the transmission range of units will decrease. We 
decrease the transmission range of MSTs and RAPs as the half of their actual range at the low level of the 
factor. 

Factor E: At the low level of this factor, when the data channels are insufficient the call requests are 
rejected. At high level, when the data channels are insufficient, the call requests are buffered, and if the 
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data channels are available, the call request is confirmed. The timeout values for request are 15 seconds 
for voice calls and video transmission and 60 seconds for messages and other data. 


4.3.1. Implementation of ANOVA 


We implement analysis of variance (ANOVA) to find out which factors and interactions have significant 
effects on the system performance. We run the model for 32 design points. To achieve independency, we 
run each of the 32 design points with different seeds and different random number streams. First, we check 
the homogeneity of variances and normality assumptions, which are to be satisfied to implement ANOVA. 
We have 32 design points, and we test the following hypothesis. 


H,: Above is not true for at least one o° 


To check homogeneity of variance assumption, we applied Bartlett’s and Levene’s test. These tests are 
widely used to diagnose the inequality of variances. The result of Barlett’s test is given in Table 4 and 
results of Levene’s test are given in Table 5. The assumption of homogeneity of variances is satisfied for 
ROUD and ROBC in both tests. 


Table 4. Bartlett’s test result for ROBC and ROUD 


Performance ROBC ROUD 
Measure 

Rg 3.617 E-06 3.272 E-06 

Q 19.313 18.073 

Cc 1.0238 1.0238 

Xi 43.437 40.647 

X 0.05,31 45 45 

Test Result | Do not reject | Do not reject 


In Levene’s test, a low significance value generally less than 0.05 indicates that the variance significantly 
differs between groups. The assumption of homogeneity of variances is satisfied for both performance 
measures. 


Table 5. Levene’s test results for ROBC and ROUD 


Performance F dfl df2 |Significance| Test Result 
Measure Value 
ROBC 1.219 31 448 0.197 Do not reject 
ROUD 1.007 31 448 0.459 Do not reject 


To check normality assumption, first, we compute residuals using regression model. Then, we construct a 
histogram of residuals. If the normality assumption is satisfied, then this plot should look like a sample 
from a normal distribution centered at zero. We also construct a normal probability plot of the residuals. 
Another procedure to check normality is to construct scatter plots of residuals. This plot of residuals 
should not show any obvious pattern. We also check scatter plot of variances. We see that there is no 
obvious patterns or structures in these plots. 


Also, note that appearance of a moderate departure from normality does not necessarily imply a serious 
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violation of the assumptions. Since the F test is only slightly affected from moderate departures from 
normality, we can say that the analysis of variance is robust to the normality assumption. But, gross 
deviations from normality require further analysis [9]. 


4.4. Evaluation of Main Effect and Interaction Effects on ROBC 


We use SPSS software package to implement ANOVA. Then, we plot the main effect and interaction 
effects diagrams to evaluate the results. The SPSS output of ROBC performance measure is given in 
Appendix E. There are three significant factors and four two-way interaction effects on the performance 
measure. The main effect diagram is shown in the Figure 4. 


Main Effect Diagram for ROBC 
0.014 
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0.008 
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—m— Factor E 0.0121 0.0069 


Figure 4. Main Effect Diagram for ROBC 


The significant factors are factor A, B and E. Factor E has an effect that decrease the value of the 
performance measure while the other significant factors have increasing effects. When a user has a buffer, 
if there is not sufficient data channel to confirm the call request, it does not immediately reject the call. 
The call request is buffered during 15 seconds for voice calls and video transmission and 60 seconds for 
messages and other data files. If there exist sufficient number of data channels in this period, the call is 
confirmed. Otherwise call is blocked. This causes a significant decrease in number of blocked calls. The 
effects of factor A and B cause an increase in the value of ROBC, since the data channel utilization will 
increase in both cases. Factor C and D have not significant effects on the ROBC. The units on the 
battlefield are positioned close to each other and they move in their responsibility area. Hence, mobility 
does not affect the distance between them significantly. Bad weather and terrain conditions will affect the 
transmission range, but this decrease in the transmission range will not affect the number of hops from 
source to destination significantly. We have also four significant two-way interaction effects. These are 
between factors A-B, B-C, A-E and B-E. First interaction effect is between factor A and B. Both factors 
have effects that increase the value of ROBC. When the brigade has five battalions, utilization of data 
channels increase. If we increase the traffic rate while the data channels are highly utilized, increase in 
ROBC will be more significant. Thus, the slope of the performance measure when one factor is at its high 
level is more than the slope of the performance measure when the factor is at its low level. Another 
interaction effect is between factor B and C. Factor B has an increasing effect on the performance measure 
and factor C has not a significant effect. The other interaction is between factor B and E. The factor B has 
an increasing effect while the effect of factor E is decreasing. The factor E has a more significant effect on 
ROBC. When the utilization of data channels is high, the factor E affects ROBC more. The interaction 
between factor A and E can be explained in a similar way as interaction between B and E. The results 
show us that as the number of messages increase in the system, the system robustness goes down. Since 
the distances between the units of the brigade in an offensive operation are not long, the effect of mobility 
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is not significant. But as the distances get longer, this effect will increase. 
4.5. Evaluation of Main Effect and Interaction Effect on ROUD 
We plot the main effect and interaction effects diagrams of ROUD performance measure to evaluate the 


results. There are three significant factors on the performance measure. The main effect diagram is shown 
in the Figure 5. 


Main Effect Diagram for ROUD 
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Figure 5. Main Effect Diagram for ROUD 


The significant factors are factor A, C and D. Factor A and D have effects that decrease the value of 
ROUD while factor C has an increasing effect. The weather and terrain conditions are the most significant 
factor. Mobility factor is more significant than the type of brigade. As the mobility increase, the distance 
between the source and destination node will also increase such that the destination is not reachable in 
allowed number of hops. The other significant factor is the type of brigade that has a decreasing effect on 
ROUD. As the number of subscribers of the same RAP increase, the network will have a more connected 
structure. The more connected network structure will cause a decrease in the value of ROUD. The traffic 
rate and existence of buffer is not significant because they do not make any change in the distance 
between users. The only significant two ways interaction effect is between factor A and D. When factor D 
is at its low level, the effect of factor A is more significant. 


5. CONCLUSIONS 


In this study we develop a simulation model for a messaging system of a model brigade. We have two 
main performance measures under interest that are ROBC and ROUD. We determined the effects of 
different factors on performance measures and finally construct different scenarios to examine the effects 
of different types of operations on performance measures. When we evaluate the system, the system 
performs well for all performance measures. It seems that the system does not have a serious problem. The 
multi-hop capability of units extends the connectivity of the network. The effect of the higher usage of 
multimedia files is negative on the system performance. Units should send this type of data, when the 
network is less congested. 


We perform 2" factorial designs to determine the effects of factors on performance measures and 
implement ANOVA to determine the factors that have significant effects on performance measures. The 
significant factors on ROBC are type of brigade, message traffic rate, and existence of buffer. The results 
show us that as the number of messages increase in the system, the system robustness goes down. Since 
the distances between the units of the brigade in an offensive operation are not long, the effect of mobility 
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is not significant. But as the distances get longer, this effect will increase. The significant factors on 
ROUD are type of brigade, mobility and weather and terrain conditions. Type of brigade and weather and 
terrain conditions have effects that decreases the value of ROUD while mobility has an increasing effect. 
The weather and terrain conditions are the most significant factor. The only two-way interaction effect is 
between type of brigade and weather and terrain conditions. As the number of units in the same area 
increase, the network will be more connected because of the multi-hop capability of units. The distance 
between units is an important factor for this performance measure. 
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ABSTRACT 


To date, legacy simulations of all operation levels have not dealt with the C4ISR aspects of the battle 
space. Nearly all of these simulations assumed either perfect C4ISR capability on both sides or employed 
some unjustified approaches to take C4ISR capabilities of the opposing forces into account. These 
approaches to modeling C4ISR did not make it possible to evaluate C4ISR systems and their contribution 
to the mission effectiveness. 


Currently, especially developed countries are well aware of the potential contributions of robust and 
integrated C4ISR systems to overall military effectiveness and working on concepts like Information 
Warfare, Network Centric Warfare and etc. Most of these countries are spending large portions of their 
budgets on procuring / developing C4ISR systems. C4ISR systems are inherently very complex and as a 
result it is very hard, if not possible, to develop architecture, concept and tactics with pure analytical 
approaches. At this point, simulation seems to be the most suitable candidate for this kind of C4ISR 
analysis. 


This paper will present a detailed description of the Command, Control, Communication and Computer 
Analysis Tool (C4AT) that is currently being developed by the Turkish General Staff Scientific Decision 
Support Center. When the first version is completed, the tool will be capable of simulating peace time 
activities of the strategic and operational level command and control centers. The second version will also 
have the ability to simulate and analyze crisis and conflict time activities of the similar command and 
control centers. 


1.0 INTRODUCTION 


The study of complex systems that have many actors and their interactions often becomes too complex for 
a mathematical model. Agent-based modeling is a tool to study these kind of systems. The tricky part of 
this modeling tool is to specify the environment, agent-knowledge model and the interactions between the 
agents. 


A software agent can be defined as any type of software entity that fulfills the basic concepts of agency. 
Ferber defines the properties of a software agent as follows [Ferber 1999] : 

¢ An agent is capable of acting and modifying its environment 

¢ An agent can communicate with other agents in the environment 

¢ An agent has intentions 

« An agent controls some local resources 


Paper presented at the MSG-022/SY-003 Conference on “C3I and M&S Interoperability”, 
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¢ An agent is capable of perceiving its environment to a limited extent 
¢ An agent has only a partial representation of its environment 
¢ An agent possesses skills and can offer services 


The need for simulating a group of agents in an environment leads to the development of Multi-Agent 
Systems (MAS). Weiss gives the following characteristics of multi-agent environments [Weiss 1999]: 
They provide a basis for specifying interaction and communication protocols; they are mostly open and 
have no centralized designer; they contain autonomous and distributed agents that may be cooperative or 
self-interested. Instead of defining MAS characteristics, Ferber reports elements that comprise a MAS. 
These elements are environment, objects, agents, relations, operations, and operators. Environment is a 
space in which every object of the MAS resides. Everything in the environment is an object. An agent is 
also an object in the environment that satisfies agency requirements. Relations link objects to each other in 
the environment. Operations are the actions that agents can perform in order to modify the environment 
and to achieve their goals. Operators can be described as the laws of the environment. Operators are 
basically the reactions of the environment to the actions taken by agents. Constructing a MAS requires 
detailed models of these elements. 


MAS simulation is a new solution to the problem of imitating complex adaptive systems. Axelrod 
describes MAS simulation as “a way of doing thought experiments,” the goal of which is to enrich our 
understanding of fundamental systems [Axelrod 1997]. He contents that the goal of MAS simulation is not 
to find exact solutions to real world problems, but rather to provide insight into complex systems that 
conventional approaches cannot model. Therefore, modeling every aspect of the system is unnecessary. 
Axelrod proposes the famous army slogan, “Keep it simple, stupid” to the MAS simulation designers. 
Otherwise, the change in the outcome of the simulation cannot be linked to any particular variant in the 
simulation and hence makes simulation useless. However, one should also be very careful in deciding 
which aspect of the real world should not be included in the simulation. Omitting a key component of a 
system from the simulation may result in meaningless, undesired outcomes. 


command and control centers are complex organizations in nature. They contain many co-operating actors 
(agents), each having different personalities, roles, and goals. Within these organizations, many time 
critical processes take place in parallel which makes it very hard to keep track of the interactions between 
the agents. These interactions are also highly depended on the work load, which is determined by the 
outer organizations. With these properties, any command and control center can be thought as a multi 
agent system. 


Since it is too hard, if not impossible, to model such a complex system with conventional modeling and 
simulation techniques, agent-based approach has been chosen to study command and control centers, and 
a generic agent-based simulation engine is implemented. 


Section 2 describes the generic simulation engine and the methodology for creating a new project. Section 
3 deals with the communication devices and their working principles. Section 4 introduces the 
environment design. Section 5 presents detailed information on the agent architecture. Section 6 is 
intended to demonstrate a scenario in execution. Finally, Section 7 gives a summary of the study and its 
results. 


2.0 THE SIMULATION ENGINE 


In order to implement our agent-based tool for simulating command and control centers (ComConCent), 
first a generic simulation engine independent of the tool was developed. The generic simulation engine is 
actually a single software class (TBtnEngine), which is used as a base class and inherited in order to create 
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our analysis tool, C4AT. The functions of the 7BinEngine is as follows: 


¢ Enabling creation and modification of the project environment and the scenario, 
¢ Managing environment and scenario files (save and load operations) 


¢ Defining scenario agents incuding their behavioral characteristics and tasks based on the 
developed High Level Task Management Script (HLTMS) and Behavioral Transition Networks 
(BTN) architecture. 


* Accepting insertion of any project specific resources ( properties, methods, classes, data, etc.) 


¢ Allowing agents to access all the resources of the project through a C-like run-time interpreter 
developed within the scope of the study. 


¢ Running scenario with a selected time management mode (event based, real-time, and constant 
time interval). 


As mentioned above, TBtnEngine can be customized using object inheritance, thus new projects can be 
created by just over-writing the bold lined functions depicted in Figure 1. TBtnEngine controls the whole 
simulation activities through these functions. For instance, when a new agent needs to be created, the 
engine calls the CreateAgentProc function (pointer) to let creation of a project specific agent instance. 


class TBtnEngine 


΄- 


TBtnEngine TObjectBaseClass * includes, TCreateAgent createAgentProc )j; 
virtual ~ TBtnEngine { 3; 


TCreateAgent CreateAgentProc; 


virtual void SaveToStream ( TStream * stream ); 
virtual void LoadFromStream ( TStream * stream ); 


virtual void SimStarted 
virtual void SimStopped 
virtual void SimAdvanced 
virtual bool InLOS 


); 

); 

double simTime, double deltaTime ); 

TAgentBaseClass * agent, TAgentBaseClass * target ); 


΄σ-΄σ- σ΄ σ- 


void SaveToFile ( AnsiString filename ); 
void LoadFromFile ( AnsiString filename ); 


void Start 
void Pause 
void Stop 
void Advance 


Nee MeN 


TAgentBaseClass * AddAgent ()¥ 
TAgentBaseClass * FindAgent ( AnsiString name, int * index = NULL ); 


Figure 1. TBtnEngine Class Interface: new projects can be created by customizing the bold lined 
functions 


The critical point in customizing the engine is to use TObjectBaseClass as a base class to all the new 
classes. This base class enables registering any variables and functions in real time to let the run-time 
interpreter access project resources. To extend the flexibilty of customation, TBtnEngine and all of its sub- 
classes are also inherited from this class. With the customized engine, C4AT, the geographical location of 
the scenario can be set, the ComConCent buildings including their interior can be designed, the 
communication devices can be introduced and the agents can be defined. The C4AT architecture and its 
class definition are shown in Figures 2 and 3 respectively. 
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C4AT Simulation Engine Inherited From TBtnEngine 


Buildings Com. Devices 


Com. Device Links 


Assigned Node Link Phone, 


Wireless, 


Com.Device Links a ΤῊΣ 
BTN Root [| Agent Links Ι Garnier 
Type Definitions, Television, 
Parameters, Radio 
Properties, 
Methods, 
Events, 


Transitions ΓΙ Assigned Node Link 
Carrying Agent Link 


Figure 2. The general architecture of the C4AT 


class TC4ATEngine : public TBtnEngine 


TComDevices * ComDevices; 
TBuildingSet * BuildingSet; 


TC4ATEngine ( TObjectBaseClass * includes, TCreateAgent createAgentProc ); 
virtual ~ TC4ATEngine ἢ 
virtual void SaveToStream ( TStream * stream ); 


virtual void LoadFromStream ( TStream * stream ); 


Figure 3. C4AT Simulation Engine Class : The bold lined objects are extension of the project, 
and the rest are functions modified in order to customize the engine 


3.0 DEFINING THE COMMUNICATION DEVICES 


The communication devices that are employed in command and control centers can be categorized as: 
phone, radio, fax, computer, and multimedia (television, radio, newspaper, etc.). Since, speed has 
generally higher priority than information security in peace time operations, the phone is the most 
preferred communication device in such operations. 


Consequently, we started the development of communication devices with the phone. For the time being, 
the first version of the telephone communication framework is completed. In this framework, the phone is 
designed to be in one of the following states: available, waiting for dial tone, ready to dial, calling, 
connected, busy, disconnected or ringing. 


The agents are designed in such a way that they can detect if a phone is in-use, if not, they can pick up the 
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phone, wait for the dial tone, dial the number and take different actions depending on the communication 
state (calling, connected, busy or disconnected) and finally hang up the phone. 


An agent can only use three kinds of phones categorized by their ownership: the ones he carries on (e.g. 
cellular phones), the ones he is responsible for (e.g. at home, at the office), and the ones that are owned by 
his group members. When a phone rings, the agents around the phone can hear the ring. If it is one of the 
phones he carries on or he is responsible for, he immediately tries to pick up the phone. If it is owned by 
one of his group members, then he waits for a short period of time and if no one picks it up, he tries to do 
it, and else no reaction is performed. 


4.0 DESIGNING THE ENVIRONMENT 


The simulation environment consists of a set of buildings and their interior. The location of each building 
is described by its geographical coordinate in lattitude and longitude. Following the definition of the 
location, the building images are automatically displayed on the screen if corresponding data exists in the 
environment database. A sample building exterior is illustrated in Figure 4. 


Figure 4. A building exterior visualized with two different zoom levels 


In order to create building models, a building editor is developed. This editor is capable of designing 
buildings by creating each floor and their connections with other floors. Floors contain nodes (connectors, 
tables, chairs, etc.), arcs (walls, windows, doors, etc.), regions (room floors, roofs, etc.) and connections 
(walking routes, relational links, etc.). A sample building interior design is demonstrated in Figure 5. 
Every object in the environment is positioned on one of the nodes. Connections are used for defining 
possible routes that could be used for navigation and specifying relations between objects. For example, 
when an agent percepts that a phone is ringing, he first tries to go to a neighbor node of the table on which 
the phone is located by searching the connections to the table. 
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table 


agent 
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connection 


Figure 5. A building interior : The buildings are designed as set of floors. 


5.0 DEFINING THE AGENTS 


The behaviors of the agents are modeled using Behavioral Transition Networks (BTN) and a sub-feature 
defined within BTN structure called High Level Task Management Script (HLTMS). BTNs [Houlette 
2000] are firstly introduced by game developers to increase practical aspects of defining behaviors. Later 
on, they became more common and used in many other fields. In fact, BTNs are just a specialized 
approach based on State Transition Diagrams and Harel Diagrams (statecharts) [Harel 1988, Ghezzi 1991, 
Rosenblum 1994, Budgen 1994], and defined using nodes and state transitions between nodes. Nodes 
may possess sub-nodes, resulting a type of hierarchy. 


Nodes has type definitions, 
parameters, properties, 
methods, events, 
transitions and HLTMS 


transition arc 


BTN node 


parallel executable sub-BTN set sub-BTN node 


Figure 6. General Architecture of a BTN 


A modified version of BTN framework is developed for TBtnEngine. This framework has some additional 
features such as parallel executable sub-BTNs and a HLTMS. General architecture of our BTN framework 
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is illustrated in Figure 6. 


Each BTN node has its type definitions, in-going transition parameters, out-going transitions (in a 
hierarchical case based structure), properties, methods, events, and a HLTMS. BTN nodes are activated, 
executed and deactivated by transitions, HLTMS and events: on enter, on leave, on message and on 
process. Each event is a script which is executed by the run-time interpreter. All the events but on process, 


are executed from start to end at once. Execution of on process events can be interrupted by using wait or 
breakcode statements defined in the script. 


[get Editorti 
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Figure 7. Aroot BTN sample for agent behavior modeling 


=). If { Phone. State[] == "Ringing" } 
Goto Ringing [ } 

=): If [ Phone. State(] != "Available" } 

Goto Not Available [ ] 

=): If [ Phone.Hold{This4gent) } 

Goto Wait For Dial Tone ἃ Dial [ J 


Figure 8. “CALL BY PHONE” action BTN (left), transitions of “Try To Pick Up The Phone” (right) 


Each agent has a set of behaviors assigned to him, which are defined in a single BTN node (root BTN). 
Therefore, customizing that BTN node (defining HLTMS, adding sub-BTNs, etc.) also changes the 
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behavioral characteristics of the agent. In our agent design, first level BTNs, the ones directly owned by 
root BTN, are generally used for action modeling such as calling by phone, going to a location, etc. A root 
BTN and an action BTN are demonstrated in Figures 7 and 8 respectively. As seen in Figure 7, there are 
no transition arcs between action nodes, because actions are fired by HLTMS. 


HLTMS is actually a hierarchically defined script, the statements of which can be executed sequentially or 
in parallel. Some of HLTMS statements and their descriptions can be viewed in Table 1. 


Table 1. Some of the HLTMS statements 


Statement Description 

STARTPAR Starts a parallel execution (starts executing sub-script under STARTPAR in parallel) 
CANCELPAR Terminates a parallel execution 

WAIT Waits for a specified time period 

LET Assigns a value to a variable. If variable is not defined, it is created 

ADDINFO Inserts an information/data item into BTN node 

ADDINFORM Inserts an information message into a parallel execution 

ADDTASK Inserts a task into a parallel execution 


REMOVETASK _ | Removes the active task of a parallel execution 


DELAYTASK Delays execution of the active task of a parallel execution 


ISAY Sends a voice message to an agent or object (phone) 

IDO Triggers an action 

DORESULT Captures the result of an action 

LISTEN Starts listening for perception messages, information messages and tasks 

I HEAR Used inside a LISTEN statement. Enables receiving voice perception messages 

I INFORMED Used inside a LISTEN statement. Enables receiving information messages 

I SELECT Used inside a LISTEN statement. Enables selecting from tasks. The task with highest 
priority is always selected. 

LOUT Backtracks to the start of a specified LISTEN statement 


An example HLTMS for responding a phone call is illustrated in Figure 9. In the sample, the execution is 
started from the very first line. When a STARTPAR statement is reached, a parallel execution for the sub- 
statements called “Conversation Manager” is started. After that, the execution continues and reaches to 
another STARTPAR, which starts another parallel execution called “Task Manager”. And finally the 
execution reaches to a LISTEN block that contains a single WAIT statement, which causes an infinite loop. 
When “Conversation Manager” is executed, it starts listening for voice messages. If a phone rings, the 
agent gets a voice message informing him that the phone is ringing. This causes the addition of a 
“Respond Phone” task to the parallel execution called “Task Manager”. When “Task Manager” is 
executed, it starts listening for tasks. When it encounters a “Respond Phone” task, it starts executing the 
sub-statements of the task. The agent first identifies the phone to see if he has right to pick it up. If so, he 
finds the location of the phone, goes to that location and picks up the phone. If the connection is 
established, the agent says hello to the remote side and waits for a reply. If he gets the reply, he insert an 
information message to “Conversation Manager” to inform the starting of the conversation and waits until 
the phone conversation is terminated. Then, the “Conversation Manager” captures the information 
message and guides the conversation. For simplicity, the conversation part is skipped. After the 
termination of conversation, the conversation manager inserts an information message to “Task Manager” 
informing that the conversation is over. In this case the “Task Manager” hangs up the phone and starts 
waiting for another task. 
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=) STARTPAR Conversation Manager 
4G LISTEN Listening [ ] 
=|) | HEAR Phone Ringing [ }[ phone ] 
ΕΞ ADDTASK[ ] RESPOND PHONE [ phone }[ Task Manager ] [ SimTime ][-1 ][-1][ ][ LOCALv{phone}.State() == "Ringing" ] [ LOCALv{phone}.State() != "Ringing" ] [ p5 ] 
STARTPAR Task Manager 
405 LISTEN Waiting [ ] 
ΞΞ F} | SELECT RESPOND PHONE [ phone } 
9S 1 DO [0] IDENTIFY PHONE { phone } 
=] DORESULT HAS RIGHT TO RESPOND [ category } 
A 1 DO [0) FIND PHONE LOCATION [ phone } 
=) DORESULT FOUND [ location } 
= 1 D0 [0] GO TO LOCATION [ location, "Slow" ) 
ΕΠ ΤΊΞΙ DORESULT REACHED [ } 
ΕἸ | DO [0] PICK UP PHONE [ phone } 
=)-(@ DORESULT CONNECTED { } 
ey | SAY Hello! am... [ ][ phone ][3] 
EQ LISTEN [ phone ] 
3 | HEAR Hello! am calling from... { )[ ] 
a= ADDINFORM Conversation Started [ phone ) [ Conversation Manager ] 
Ge LISTEN [ ] 
ΕΙ @ | INFORMED Conversation Ended [ ] 
ΧΟ REMOVETASK [ ] 
=)! | DO [0] HANG UP PHONE [ phone } 
ΣΈ LOUT Listening [ Conversation Manager ] 
+4 LOUT Waiting [ ] 
[2 DORESULT NOT RINGING ANY MORE ( ) 
% REMOVETASK [ ] 
©} LOUT Waiting [ ] 
ΕΙ DORESULT NOT REACHED [ reason } 
XX REMOVETASK[ ] 
+} LOUT Waiting [ ] 
=f DORESULT NOT FOUND [) 
X REMOVETASK [ ] 
#7} LOUT Waiting [ ] 
=] DORESULT NOT HAVE RIGHT TO RESPOND [ } 
% REMOVETASK [ ] 
+ LOUT Waiting [ ] 


ΕἸ 


oy 


EQ LISTEN [ ] 
@} walt 60 


Figure 9. Asample HLTMS for responding a phone call 


In order to avoid implementing complex perception algorithms, which are beyond the scope of this study, 
we assumed that the agents can perceive (hear and see) any object that is at the same floor and within 10 
meters range. 


Following the development of voice and visual perception mechanism, we were able to form a 
methodology for task distribution among agents. Although there are many complex ways to introduce 
collaboration among agents [Axelrod 1997, Feber 1999, Ercetin 2001], we used a simple but effective 
model, which reflects nature of command and control hierarchy. An agent informed of a task (event, 
request, order) generates a set of sub-tasks to meet the requirements of the main-task. Following task 
decomposition, additional sub-tasks for task distribution management are inserted. For instance, if the task 
is an event, the agent generates sub-tasks of the event and an additional task for reporting to the superior. 
If the agent could not manage to inform his superior, he starts doing tasks that are not strictly depended on 
the completion of informing the superior. When he manages to give the report to the superior, the sub- 
tasks not completed yet are fully canceled, because because they will be distributed by the superior. Then 
the superior generates a list of sub-tasks for himself and for his sub-ordinates, and distributes the sub-tasks 
to his sub-ordinates considering the work load. 


The path planning of agents for navigation is another challenging problem to be solved. Path planning is 
defined as searching for a set of state transitions to reach to a goal location from an initial location. It is 
cetegorized in to two: off-line [Deloura 2000] and real-time [Undeger 200la, Undeger 2001b] path 
planning. Off-line path planning has the advantage of generating high quality routes, but takes much CPU 
time and not suitable for highly dynamic environments. On the contrary, real-time path planning 
algorithms give poor solution quality, but is highly interactive and very adaptive to changing conditions. 
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The technique employed in our study is off-line path search through the connection graph, which is 
discribed in Section 4. 


6.0 RUNNING THE SCENARIO 


Once the behaviors and tasks of agents are modeled, the next step is to run the scenario. This function is 
directly supported by TBtnEngine. The TBtnEngine allows selection of time management metodology and 
simulation time multiplier. There are three main time management modes: event based, real-time and 
constant time interval. In the event-based time management mode, the events are tracked in the order that 
they will occur and the simulation is advanced to the nearest one. Therefore, the scenario is run as fast as 
possible in this mode. This mode is currently under development. The second mode is real-time, in which 
the time is advanced in parallel with the real-time (or a multiplier of real-time). In this mode, there is a 
possibility that the advance of a single step of the simulation will take more time than desired. For this 
reason, this mode is divided into three sub modes: unlimited time steps, constant time steps, upper 
bounded time steps. If unlimited time steps mode is used, the simulation time steps continue until all the 
related code is executed. If constant time steps mode is preferred, the execution is interrupted and passed 
to the next step when the specified constant time is exceeded, else a delay is inserted to reach the specified 
constant time. In upper bounded time steps mode, the execution is interrupted and passed to the next step 
if specified constant time is exceeded. The last time management mode, constant time interval, is 
generally used in debug mode, which ignores real-time and advances simulation time with constant time 
step, no matter how much time the step actually takes. 


After starting the simulation, the simulation state can be observed on visualization window and messages 
are printed on the message window. The environment, the location and body posture of agents, the state of 
devices and the messages exchanged are all shown on visualization window. The messages (BTN 
execution messages, HLTMS execution messages, and run-time interpreter messages) are printed to the 
message window. The visualization and message windows are shown in Figure 10. 
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Figure 10. Asnapshot of the simulation in execution 


16 - 10 RTO-MP-MSG-022 


Modeling Command & Control Centers 


7.0 CONCLUSION 


In this paper, we have proposed a simulation framework and a simulation tool for modeling command and 
control centers. First, we have started with the definition and properties of software agents, and clearly 
stated the reasons for developing our framework on top of agent based systems. Later, the generic 
simulation engine designed to realize the framework, and the customized engine for C4AT have been 
presented in detail. We have mostly focused on our agent-based system, which employs Behavioral 
Transition Networks and a newly proposed approach called High Level Task Management Script. For 
C4AT analysis toolkit, a communication framework and an environment design is developed and a sample 
scenario is generated. The first version of our implementation has given promising results for modeling a 
larger scenario that covers all the functions of a ComConCent. Thus, we are currently studying on the tool 
for defining new agent behaviors and tasks to improve the system. 
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1. INTRODUCTION 


Command, control, communication and intelligence (C31) systems as well as simulation systems belong to 
the class of model-based information systems. This is obvious in the case of simulations, which are always 
based on models. But C3I systems, too, have to be based on models of the corresponding real world 
processes in order to manage the tremendous complexity of military systems. The latter becomes 
immediately clear when thinking of terrain representation in form of military maps, which are a perfect 
example for reliable models. However, since model designers necessarily abstract and simplify reality 
according to their own perception and conceptions, models can significantly differ in several aspects. 
Experiments with the high resolution combat simulation system COSIMAC (developed at the Institute for 
Applied Systems Science and Operations Research (IASFOR) at the University of the Federal Armed 
Forces Munich, Department of Computer Science) and some modules implementing basic (31 
functionality (command and control modules) have shown that there are some essential preconditions for 
coupling such model based information systems. Our results indicate that technical and syntactic 
preconditions (addressed by HLA and ATCCIS, for example), which have been in the focus of interest for 
almost a decade, are not sufficient to guarantee a successful interaction. The crucial tasks are to ensure that 
syntactical structures are attributed with the same meanings in all involved models and that the same 
actions are triggered by identical orders and reports. These findings have been confirmed during a study 
we performed for the German Armed Forces addressing the standardization of command and control 
components for different Army simulation systems. As a consequence of the importance of meanings and 
triggered actions we have chosen a linguistic approach to understand the problems of interoperability, 
which is based on the idea of successful communication between models / model users. That might seem a 
bit strange at first sight, but regarded from the perspective of the model designer, the coupling of models is 
in fact a sophisticated kind of communication with his counterpart. 


In linguistics one generally presupposes the existence of a technical communication channel (which is so 
important in computer science) and concentrates on the three semiotic aspects of language which are 
syntax, semantics and pragmatics. Linguistics provide a perfect framework for investigations into the 
meaning of interactions, since the whole point of setting up a theory of semantics and pragmatics is to 
provide a systematic account of the nature of meaning. Communication is successful if and only if sender 
and receiver have common knowledge on all semiotic aspects. Based on our experiments, this paper 
discusses several examples of failed coupling at the level of semantics and pragmatics. Generalizing these 
results we conclude that there are at least four compulsory preconditions (1-4) for C3I/M&S 
interoperability and one desirable precondition (5), by name: 


Paper presented at the MSG-022/SY-003 Conference on “‘C3I and M&S Interoperability ”, 
held in Antalya, Turkey, 9-10 October 2003, and published in RTO-MP-MSG-022. 
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(1) Automatically processible data (syntactical standards) 

(2) Standardized algorithms (for data fusion and aggregation) 

(3) Similar or at least compatible model development approaches 
(4) Collated triggering of actions 

(5) Standardized GUI and uniform SW ergonomics. 


Since the mere presentation of coupling problems stemming from a limited amount of models would be 
too anecdotic and idiosyncratic to be convincing, the paper first introduces a general framework (sections 
2 — 5) in which the examples presented in chapter 7 fit as illustrations of the basic ideas. Section 6 
provides the reader (non-insider) with some fundamental information about ground combat simulation 
systems. 


2. MODEL BASED INFORMATION PROCESSING SYSTEMS 


From a general point of view information processing systems can be distinguished into direct and 
intermediate control information systems (see Figure 1): Most of the (artificial) information processing 
systems used today are embedded into real systems in which they operate as control units. Their task is to 
ensure that the state transition of the real system stays within a given trajectory. Such information 
processing systems exert direct control over the system they are part of (f° -function in Figure 1). 
Examples for this kind of information systems are electronic devices like anti-lock braking systems or 
electronic traction control systems in cars. On the other hand there are information processing systems that 
do not manipulate the real system states directly. One possible reason for this is that in these systems the 
space of possible state is much to great to be held under control directly. Via abstraction and idealization 
(-function in Figure 1) a model of the real system is created. Within this model one tries to achieve 
control over the dynamics of the assumed states (Z™, and not Z°). In general, this is done by postulating 
causal dependencies between different states. After execution of the model (f-function) it is necessary to 
“retranslate” from Z™ to Ζ᾽ (w-function). Now it is possible to check in the real system whether the 
predictions of the model are valid ore not. If they are, it is assumed that M is a helpful model of the system 
S and wep “eg is regarded to be a good substitute for B°. 
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Figure 1: Direct and intermediate control of dynamics in systems and models 
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It is obvious that all simulations are examples of model based information processing systems. Combat 
simulation systems are almost perfect instances of this class. But C3I systems too, have to be regarded as 
model based. Starting with the company level and intensifying above it, military command is based on 
models of the real combat situation. The direct processing of observations can only be the foundation of 
combat control on the weapon system and (to a certain extent) platoon level. Working with tactical 
symbols on terrain maps is as much model based as simulation. 


3. MODELS AND THE NEED FOR COMMUNICATION 


Whenever models 4 and B of systems A and B are combined, it is necessary to ensure that both models 
share a common conceptual picture C of the supersystem C (see Figure 2). 


Common 
Conceptual model C 
of the supersystem C 


Real world 


ὡς supersystem C a 
x ‘ consists of: ig Υ 
developer \_A Β ’ developer 


Figure 2: Models, communication and validation 


Whereas it is clear that the supersystem C has to be a superset of A and B (at least if one does not 
deliberately omit aspects of the real world modelled in A or B), it is not self-evident that the common 
conceptual model C is likewise only a superset of A and B. In fact, in most cases it is necessary to start 
with the intersection set of A and B and extend or adjust it in order to create a common conceptual model. 
As an example let us consider two different ground combat simulation models and their terrain 
representation. The supersystem terrain T(C) has to be a superset of the real terrains T(A) and T(B) 
modelled in A and B. The exact definition of this superset should not be a challenging problem even if 
T(A) and T(B) are completely separated and we have to define an additional connecting “corridor”. 
Unfortunately, the models of the terrains 7(A) and 7(B) can differ so much from each other that even if 
T(A) and T(B) are identical, a common terrain model 7(C) is extremely hard to develop. Let us assume 
that T(A) is a vector model and 7(8) a grid model. There is no common conceptual model for these two 
types of terrain representation. One has to give up one of them or integrate both approaches into both 
systems. Even with two grid models serious problem can occur if 7(4) and 7(B) do not distinguish 
between the same terrain types (forest, urban, open terrain, water, etc.) or do not use the same algorithms 
to compute trafficability values from terrain type, slope and weather conditions. Using the formalism 
introduced in the previous chapter, the problem can be stated as follows: It is relatively easy to combine 
two system state sets Z*' and Z* but in order to combine two model state sets Ζ and Z™’, the different 
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abstraction and idealization functions ~' and ¢” (and subsequently B™' andB™’ and also ψ' and y” have to 
be reconciled. Whereas set theory provides powerful means for the first task, there are no general methods 
for the second one, since abstraction and idealization are in themselves not approachable by formalization. 
Consequently, finding a common conceptual model for two models developed from different persons X 
and Y requires intensive communication between X and Y about o', φ΄᾽, B™', B™ , ψ' and w’. Despite this 
challenge it is very assuring that the basis for validation, the real supersystem C is generally much less 
disputable than C. Thus, checking whether the coupling of the models was successful or not normally has 
a sound foundation (essential for validation). Reconsidering our example, one can easily prove if a vehicle 
movement possible in your coupled model would have been possible in the real terrain. 


4. A LINGUISTIC PERSPECTIVE ON MODEL COMMUNICATION 


After realizing that personal communication is almost inevitable in every model coupling project it 
becomes essential to ensure successful communication. Unfortunately, there exists no universal formal 
language that could grasp the whole variety of abstraction and idealization possibilities. Thus, at least 
some part of the communication process between the modellers will be natural language communication. 
The special branch of science that deals with successful natural language communication is linguistics, 
which differentiates syntax, semantics and pragmatics of an utterance in language. Since most people are 
familiar with syntax and semantics but not with the linguistic concept of pragmatics a short description 
may be helpful. In the semiotic trichotomy developed by Charles Morris, Rudolph Carnap, and C. S. 
Peirce in the 1930s, syntax addresses the formal relations of signs to one another, semantics the relation of 
signs to what they denote, and pragmatics the relation of signs to their users and interpreters [1-3]. The 
central rationale for pragmatics is that sentence meaning (semantics) in natural languages vastly 
underdetermines speaker’s meaning (intentions). The goal of pragmatics is to explain how the gap 
between sentence meaning and speaker’s meaning is bridged [4]. 


In “linguistics words” (which sometimes seem a little bit convoluted), pragmatic information concerns 
facts relevant to making sense of a speaker's utterance of a sentence (or other expression). “The hearer 
thereby seeks to identify the speaker's intention in making the utterance. In effect the hearer seeks to 
explain the fact that the speaker said what he said, in the way he said it” [5]. Because the intention is 
communicative, the hearer's task of identifying it is driven partly by the assumption that the speaker 
intends him to do this. The speaker succeeds in communicating if the hearer identifies his intention in this 
way, for communicative intentions are intentions whose "fulfilment consists in their recognition" [6]. In 
other and much simpler words, pragmatics is concerned with whatever information is relevant, over and 
above the linguistic properties of a sentence, to understanding its utterance [4]. It should be mentioned that 
even Noam Chomsky, the world’s most famous and influential linguist has stated that “a general linguistic 
theory must incorporate pragmatics as a central and crucial component” [7]. 


As an example consider a mountain walk of an experienced climber and his friend, who has always stayed 
in flat land. During the walk the climber shouts “Stone” and expects his friend to seek for shelter. 
Unfortunately, his friend doesn’t even raise a hand. On which communication level occurred the error? 
We can assume that the flatlander heard what his friend said (physical transmission), understood the 
phoneme “stone” and mentally translated it into the correct word “stone” (syntactic level) and knew what 
a stone is (extensional meaning of the word, semantic level). Hence the fatal error must have occurred on 
the pragmatic level as an failure of communicating the demand of action. 


It is obvious that the line between semantics and pragmatics cannot be absolutely definite and that some 
aspects of contextual information and other connotation could be placed into the semantic bucket, too. (In 
the example, one could argue that the semantic of the word “stone” in the context of mountain hiking has 
to be extended.) But in general it is not recommended to extend the borders of semantics, because it 
quickly leads to person dependent ambiguity in semantic definitions (What if a geologist shouts stone 
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during a mountain walk? Is he delighted or terrified?). 


However, taking the nature of pragmatics into consideration, it is no surprise that it has been omitted in 
computer and many other sciences. The general guideline in all natural and technical sciences is to reduce 
subjective factors down to zero. Hence scientists from this research areas seek to find or define a 
pragmatics-free (context, connotation and especially individual opinion free) experimental system. 
Unfortunately, that approach has strong limitations whenever human behaviour and communication have 
to be regarded. To a certain extent developing models for complex dynamic systems is always a subjective 
endeavour, especially when taking into consideration the different purposes, scales, user modes and 
resolutions of models of such systems, the degrees of freedom within each of these aspects and the 
necessity to tailor each model to fit the purpose. 


So far the linguistic aspect of pragmatics has been emphasised. The following sections changes the focus 
to the relationship between models and pragmatics. As an introduction to this relationship consider the 
definition of semiotic qualities of conceptual models (see Table 1) given by [8]. 


Table 1: Definition of semiotic qualities of conceptual models (Lindland et al. 1994) 


Syntactic quality |The degree of correspondence between a conceptual model and its representation. 


Semantic quality | The degree of correspondence between the conceptual model and the real world. 


Pragmatic quality |The degree of correspondence between the conceptual model and its (individual) 
interpretation. 


One of the central dogmas of modern computer science is the demand for unambiguous programs that can 
be used without any additional context information (information hiding). Especially for component- 
based software architectures this requirement is said to be essential. Taking this dogma literally implies 
that documentation of programs mustn’t be essential for model understanding and application but only 
(extremely) helpful. Ideally the program/module itself (as a sequence of statements in a programming 
language) should contain the whole meaning/sense of the underlying (conceptual) model. 


I do not doubt that from the perspective of software engineering this dogma is completely justified. There 
actually is a huge amount of software that fulfils this black-box criteria. However, as far as I can see, these 
programmes are of a very fine granularity, and very often monofunctional. The simplicity of these 
components in terms of degrees of freedom is the reason why the black-box approach works. However, to 
base a general hierarchy of domain specific components - that finally would lead to complex 
multifunctional modules - on a black-box architecture is most probably an illusion of current software 
engineering. In complex military, economic or logistic simulation systems the code vastly 
underdetermines the modeller’s ideas and intentions. Therefore, model documentation in natural 
language and additional verbal communication, despite all their disadvantages of ambiguity and 
connotations, are essential parts of the interaction among model developers and users. 


5. THE PROBLEM OF HIDDEN ASSUMPTIONS 


The hard part of developing simulation systems of complex dynamic systems is not code generation but 
appropriate modelling which is mainly abstracting and idealizing. If all abstraction and idealization a 
modeller has used in building a model were easily discernable or well documented, it would be possible - 
in terms of the framework introduced in chapters 2 and 3 - to exactly define and understand the g- , Bp” 
and w-functions underlying the model. Unfortunately, almost every modeller uses assumptions which are 
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not documented and hard to reengineer from the executable model if one does not know what to look for. 
In general, one gets to know about hidden assumptions the hard way: the model-federation produces 
nonsense and it is extremely difficult to explain it. Naturally, it would always be possible to make a 
special assumption transparent. The problem is, that in the modelling of complex systems there are so 
many assumptions involved that completeness can hardly be assured. In addition, there are assumptions 
which are taken for granted and therefore not documented. But “self evident facts” are sometimes quite 
disputable. 


Something that is often hidden in the description of ground combat simulation systems is the scope of the 
perceived situation. Every unit and every command level has a perceived situation, which differs from the 
real situation according to their current information respectively information deficits. In reality, this 
“picture of the battlefield” is convoluted mix of own perceptions, messages, orders, situation updates from 
higher and lower echelons, adjacent units and even civilian information sources. It is extremely difficult to 
keep all this pictures consistent. Therefore, there is always a scope of the perceived situation of a unit 
which denotes which and how many other units currently share a consistent variant of it. Because of its 
complexity the real development and updating process of the perceived situation is simplified within the 
simulation systems. How this simplification is done depends on many factors, especially purpose and 
resolution of the simulation system. When we tried to find it out for the combat simulation systems listed 
in the next chapter, not one model documentation was sufficient and I venture to doubt that all the 
modellers of these systems were fully aware of the problem. 


It may be a subjective opinion, but I am absolutely convinced that it is impossible to reduce hidden 
assumptions in models of complex dynamic systems down to zero. As a consequence there will always be 
the need for an intensive test and adjustment phase after a technically successful coupling of such models. 


6. GROUND COMBAT SIMULATION SYSTEMS AND C3I SYSTEMS 


Over more than two decades scientists at our Institute (IASFOR) have analysed ground combat simulation 
systems used in the German and other armies (for example: JANUS, HORUS, GESI/SIRA, PAPST, 
KORA, IRIS [9-12] and designed and implemented own simulation systems (see below). The level of 
complexity of these models reaches from simplified test simulation systems and relatively simple 
simulations based upon cellular automata (ZEGA and ZELGAT [13]) up to full scope aggregated land 
battle models (KOSMOS [14]) and high resolution ground combat models (BASIS [15]), COSIMAC-P, 
COSIMAC-WS [13]), which are in terms of system theory [16] extremely complex. In addition, we have 
recently compared three of these systems (GESI, HORUS and our own model COSIMAC) in a study. The 
goal of this study was to assess the feasibility of standardized command and control (C&C) modules for 
high resolution combat simulation systems. The study was also part of the preparing efforts towards a new 
German ground combat simulations system (“SimSys Einsatz Heer”), which is intended to be integrated 
into the new German C3] environment. Before discussing the results of this study, a short introduction to 
ground combat simulation systems is given. 


Ground combat simulation systems (GCSS) are a very heterogeneous class of models ({13], [17]), 
nevertheless they all share some fundamental parts. Every GCSS has to model the following aspects of 
combat: 

1. terrain and environmental representation, 

2. movement, 
3. attrition, 
4 


transportation (at least of ammunition), 
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5. communication and 
6. reconnaissance. 


Generally, GCSS are discrete event simulations based upon an event queue. The GCSS mentioned above 
aren’t real time simulations, anyway internal time management is essential. If the GCSS is used for 
analysis in a closed simulation it is necessary to add 


7. command and control modelling, 
which shouldn’t be a part of the central simulator - for reasons explained in [13]. 
The major distinctions between the models, beside different purposes (acquisition, decision support, 
analyses, training), scopes and user modes (closed simulation or interactive), is their level of resolution: 


the level of detail at which the real world system and its behaviour is modelled. Referring to [18] and [19] 
resolution in combat simulation systems has six “components”: 


attributes and 


1. temporal scale, 
2. spatial scale, 
3. processes, 

4. entities, 

ὃ: 

6. 


dependencies. 


This classification is arguable, but useful to illustrate the degrees of freedom for the modelling. It has been 
shown (see for example [18]) that it is far from trivial to ensure consistency between models of different 
resolution. 


In terms of the theoretical framework introduced in section 2 different purposes, scopes, user modes and 
resolutions all tend to increase the deviations between the @—functions and consequently between the p™- 
functions of two models. Thus, even with completely congruent real systems A and B (C = A = B) 
deviations between the models 4 and B can be too great to find a satisfying common model C. 


The development of command and control (C&C) modules for GCSS is not only the precondition to 
reduce the amount of interactive operators in command post exercises, it is also a precondition for using 
GCSS as decision support tools. Moreover, it is essential to realize that the integration of GCSS into (31 
systems will only be successful, if the C&C-modules in the simulations operate on the same principles as 
the automatism applied within the C3I system. Otherwise, the simulation of courses of action in advance 
would be very dubious. As an example consider the problem of data fusion. The same algorithms that 
process (connect, condense, countercheck etc.) real messages in C3] systems have to be applied within the 
simulation in advance in order to keep its situation update consistent. 


7. ESSENTIAL PRECONDITIONS FOR SUCCESSFUL COUPLING OF MODEL 
BASED INFORMTION SYSTEMS 


With the basic considerations presented in the previous sections it is now possible to highlight the results 
of the research at our institute and to establish the essential preconditions for successful coupling of model 
based information systems. In the following it should be reminded that the conclusions presented here are 
drawn from projects within the simulation domain. It has to be admitted too, that the expertise of our 
institutes (IASFOR and ITIS) covers more of this domain than of the traditional Command, Control, 
Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) domain. 
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7.1 Technical aspects 


We have coupled different versions of our own COSIMAC combat simulation systems via the HLA, 
CORBA and a simple self-made TCP/IP interface within a local area network. Although all of these 
solutions had some drawbacks, most of the basic technical functionality for interoperation could be 
provided. There are major differences between these solutions when it comes to additional services 
(authorisation, time management, security etc.), flexibility and maintainability, but these differences also 
show that different approaches can do the job. So far, there is no technical framework for interoperation 
that comprises all advantages and avoids all drawbacks — and maybe such a framework will never exist. 
But the reassuring result of our own research is that most of the problems with imperfect technical 
architectures are surmountable. Therefore, if there is any real problem for coupling simulations and (31 
systems at the technical level, it will be the problem of unification on the basis of a not disputed 
standardisation. 


7.2 Syntactic aspects 


The first precondition for coupling model based information systems are automatically processible data 
(terrain, weapon systems, personal, organisational, tactics etc.) in the very straightforward sense of 
standardized syntactic structures that may lead to a formal military language. The range of the standard 
determines the range of easy interoperation. Thus, NATO-wide standards are preferable. The Land 
Command and Control Information Exchange Data Model (LC2IEDM) was an important step in that 
direction. Without a common syntax the coupling of simulations and C3I systems is hardly thinkable, 
since syntactic transformations between different models are much too cumbersome to be feasible within a 
multinational environment. The challenge on this level is put by general drawbacks of all formal 
languages in comparison to natural languages. First, whereas there are many different personal incentives 
to learn a foreign natural language, the use of a formal language has to be enforced. Second, no formal 
language can capture to whole expressiveness of a natural language. Third, most of the difficulties of 
misunderstandings in natural languages occur on the pragmatic level of communication. Such 
misinterpretations of persons you use a language can happen with formal languages as well. Formality 
could therefore evoke fallacious trust. 


7.3 Semantic aspects 


I have addressed technical and syntactic issues only briefly because there is so much other work done in 
this fields and I have to admit that we did not find out something really new in our studies for these levels. 
On the semantic level, in contrast, there are some challenges which have been underestimated. It is self- 
evident, that the semantic meanings of syntactic structures have to be defined according to common use or 
a predefined ontology. In general, that leads to a kind of glossary or lexicon, attributing meanings to 
character strings. During the efforts to integrate command and control modules into our GCSS we realized 
that such a lexicographic summary is not sufficient to guarantee consistent interoperation. What is needed 
in addition are standardized algorithms for the modelling of elementary processes like attrition, movement, 
data fusion, reconnaissance and communication. In order to explain this need, an illustrative example 
might be helpful. In high resolution GCSS it is necessary to model reconnaissance of individual combat 
vehicles like tanks and AFVs (Armoured fighting vehicle). This can be done with regularly “glimpses “ or 
sector scans, with global detection probabilities or, in grid models, with individual terrain cell checks, to 
name just a few possibilities [17]. The algorithms behind these methods lead to different perceived 
situations, since detection of enemy entities will not occur at the same simulation time. However, 
perceived situations are the most important information for any command and control module. Hence, the 
reconnaissance algorithm influences the course of action chosen from the C&C module. A module devised 
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in the context of a “glimpses” model is therefore not directly applicable to a cell check model, even if all 
messages and orders the C&C module gets are standardized in both models, or with other words, even if a 
standardized interface between high resolution GCSS and additional C&C modules exists. One can easily 
transfer this example to the problem of data fusion which has to be solved both in simulation systems and 
C4ISR systems. Different fusion algorithms will lead to different estimates of the situation. A simulation 
in advance using its own data fusion algorithm would differ from the real course of action perceived after 
using the (931 data fusion algorithm even if the initial situation would evolve as predicted. Using our 
theoretical model, the problem can be simplified into the following consideration: With a static lexicon of 
standardized terms only the g-functions of the model building process are addressed. The dynamic 
processing of model states via the B“-functions (algorithms) remains largely unconsidered. 


On the other hand there are even examples that consistent @-functions cannot be guaranteed only with 
semantic lexicons. A perfect example are deterministic and stochastic models based on otherwise identical 
representations. Let us first assume that two simulation systems have to interoperate. One system uses 
deterministic parameters and the other determines averages from a certain amount of stochastic simulation 
runs. It is very well known, that the value of averages highly depends on the underlying distribution. Any 
discrete distribution similar to the continuous probability density function sketched in figure 3 would be 
an extreme counterexample for the use of averages. 


A f(x) 


Average 


Figure 13: Sketch of a double peak probability density function (PDF) 


If the stochastic simulation provides the deterministic simulation with the results of its stochastic runs in 
the form of such an average, further simulations within the deterministic model are almost useless. The 
same would hold true if we replace the deterministic simulation with a deterministic C3I system. 
Stochastic and deterministic models of a system are the result of two different @-functions, which are not 
always compatible without further considerations (about variance for example). Similar problems occur, if 
discrete and continuous or event and process driven or descriptive and predicting models are connected. It 
is possible to couple such models in a sensible, purpose-driven way, but only with adjustments that go far 
beyond even a sophisticated glossary. Consequently, a third essential precondition for coupling model 
based information systems are similar or at least compatible model development approaches. 


7.4 Pragmatic aspects 


Pragmatic aspects of interoperation deal with the actions (state transitions) triggered within a person or 
any other information processing system after receiving, decoding and semantically understanding a 
transmitted information. We are all familiar with the problem of the huge variety of possible actions and 
state transitions a human being possess in a communication. In order to be successful in triggering the 
desired actions or state transitions in the receiver the human sender (speaker or writer) has to take into 
account the probably different attitudes, beliefs, physical skills, mental capacities, physical and emotional 
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constitutions, social and cultural backgrounds of his counterparts. In general this is done unconsciously as 
a consequence of lifelong learning. Nevertheless, most of the unsuccessful communications between 
humans occur on the pragmatic level. The very reason for this problem is that it is relatively easy to define 
the semantic meaning of a word or sentence, but impossible to find a general agreement on the pragmatic 
influence factors attitude, belief etc. 


It may seem that this problem has little to do with the challenge of coupling artificial model based 
information systems like simulation or C3I systems. Unfortunately, as has been shown in chapter 3 and 4, 
the coupling of models always involves human communication problems. Therefore it should be expected 
that errors on the pragmatic level can be found whenever model driven information systems are coupled. 
That is exactly what we find out. I do not want to discredit any of the models mentioned in chapter 6 
except our own. Thus, I am not going to use these model names in the following examples. 


The most striking examples of different pragmatics in GCSS we found in command and control modules. 
The variety of possible actions and state transitions triggered from an “immediately attack objective Z” 
order given to different C&C module is impressive, even in the very homogeneous context of the 
COSIMAC GCSS. Different programmers (within the COSIMAC project all programmers where active 
officers, too) assume different state transitions according to their mental picture of reality. The first variety 
has been introduced by the evaluation of the term “immediately”. The range of possible and actually 
realized pragmatic interpretations spans from “abandoning all other tasks” and “immediately” start 
moving with available unit members at maximum speed, to the assembly of scattered unit members and 
regrouping, followed by a movement optimisation based on speed and coverage. 


A similar problem has been the exact state transition after reaching the objective. Most COSIMAC 
programmers (modellers!) stopped the attacking units after reaching the objective and deployed them 
within a predefined area in order to establish an all-around defence. However, some implemented a kind 
of opportunity function, allowing the attacking units to progress, if (a) inferior enemy units could be 
destroyed or (b) tactical localities could be seized. In general, the challenge of such flexible modules 
(mission-types tactics) is to ensure that the higher commanders intent (presumable the part of an order 
which defies formalisation the most!) is always taken into account. 


Which behaviour is adequate depends on circumstances and reflects to a certain extent the degree of 
freedom a human decision maker has in the same situation. A further refinement of the models would have 
been necessary to overcome this problem. However, according to the abstraction and idealization level 
chosen for the model there is always a limit for such extensions, especially in rule-driven modules 
(consistency!). Additionally, the pragmatic problems tend to increase with higher resolution, since more 
idiosyncrasies of terrain, situation and mission have to be regarded. 


These findings which have been first realized during the development of C&C modules for the GCSS 
COSIMAC, have been strongly supported by research on other GCSS of similar resolution (HORUS, 
GESI]). Even if syntactic and semantic inconsistencies could be overcome, pragmatic issues would impede 
many interesting and sensible interoperations. Details of this research can be found in [20]. 


It is essential to realize that inconsistency problems like those mentioned above are not consequences of 
bad modelling but consequences of the modelling of complex dynamic systems in itself. 


Moreover, during efforts to integrate the human factor “willingness to take risks” in the GCSS COSIMAC 
we realized that the variety of possible, but unfortunately inconsistent interpretations can only be curbed 


by extremely simplifying assumptions which have little to do with reality. 


What all of these examples clearly show is, that the actions triggered within a GCSS after receiving a 
semantically well defined message or order can significantly and inconsistently differ. Thus, even if we 
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have eliminated all ambiguities through unequivocal semantic definitions model coupling can still fail. 
Fortunately, for most of the examples mentioned above it is possible to fix a kind of reference model with 
standard actions and state transitions — which is the fourth essential precondition of coupling model based 
information systems. 


The last aspect of interoperation addressed in this paper is theoretically less compulsory than the previous 
ones but maybe of equal importance in practice. The briefing efforts necessary to use different simulation 
and (31 systems is tremendous. This labour should not be complicated by different graphical user 
interfaces (GUI) and other aspects of SW ergonomics. Again, a kind of standard should be designed, 
including the arrangement of menus, statistical information and scenario editors. Otherwise, no single user 
will be able to keep an overview and face validation would be impossible. 


8. SUMMARY, CONCLUSION AND A CRITICAL REMARK 


The successful interoperation of model based information systems is not only a technical or syntactical 
problem. Most of the real challenges occur on the semantic and even more on the pragmatic level. The 
only practicable way to overcome these challenges are strict standardisation or (and) time consuming 
additional test and adjustment phases with the model federations. The arguments presented in this paper 
have been confirmed by examples from the simulation domain. However, the author is convinced that 
similar experiences have been made in the traditional C3I domain. 


The main conclusion for the coupling of NATO simulation and C3I systems is that the scope of 
standardisation should be extended to pragmatic issues, too. For that reason, it is necessary to unfold the 
conceptual models of the simulation or C3] systems as clear as possible. 


It should be remembered that the models developed in operations research should always be tailored to 
solve one special problem or to fulfil one special purpose. Coupling them often implies to blur specific 
adaptations of the models to their original purpose. “Monolithic” should therefore not become a negative 
attribute in itself. 
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ABSTRACT 


The 1998 Computer Generated Forces (CGF) Conference included a paper [1] which proposed a 
Technical Reference Model (TRM) for interoperability between U.S. Command, Control, Communication, 
Computers, Intelligence, Reconnaissance, and Surveillance systems (C4ISR)' and Computer Generated 
Force simulations (Sim). This TRM characterized the “type of information that is necessary to pass 
between C4ISR and CGF systems”. Since then, changes have occurred in technology for interfaces; the 
uses for interfaces; and the Architecture(s) upon which they are based. In addition, significant changes 
have occurred in the respective source and target systems that these interfaces connect, namely C4ISR 
systems and simulations. Finally, substantial interest has been expressed in the availability of C4ISR 
hosted simulation components, as well as the integration and exchange of components between the two 
domains. A recent Simulation Interoperability Standards Organization (SISO) Simulation Interoperability 
Workshop (SIW) paper [2] has proposed substantial changes to reflect the evolution of technology, 
supported systems, current interface practices, and near term future uses for C4ISR — M&S interfaces. 


This paper briefly describes the revised version of the TRM. It suggests when and how to use the TRM in 
reference to NATO Command, Control, Communication, and Intelligence (C31) system to modeling and 
simulation (M&S) interoperability or integration efforts. It shows the TRM’s relationship to current NATO 
models and standards in the C3I domain, as an aid to those concerned with interoperability, integration, 
or standardization efforts between the two types of systems. The paper explores the use of the TRM in light 
of NATO interoperability efforts, and reflects on the relationship between the C4ISR/Sim TRM and NATO 
guidance documents/standards such as the NATO C3 Technical Architecture (NC3TA), the NATO 
Common Operating Environment (NCOE) Model (NCOM), and others. 


1.0 INTRODUCTION 


In 1998, a TRM for interoperability between C4I systems and simulations was developed and proposed to 
the 1998 Computer Generated Forces Conference [1]. Since first proposed, the TRM has generated a 
substantial amount of interest within the US C4I — M&S interface community, particularly within the 
Simulation Interoperability Standards Organization (SISO) Simulation Interoperability Workshop (SIW) 
conferences. It has been the focus of several SIW study groups intended to “formulate a broad-based 
technical model to describe and categorize interoperability of systems or classes of systems” [3,4,5]. The 
work and discussion of these groups continues, as well as their desire to “leverag[e] existing work and 
foster development of that TRM into a formal SISO product.” 


' C4ISR systems are the US DoD functional equivalent to NATO Command, Control, Communication, and Intelligence (C31) 
systems 
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Figure 1 - C4l - M&S Interoperability Technical Reference Model 


At the Spring 2003 SIW, the author proposed substantial changes to the TRM [2], as reflected in Figure 1 
(Following page). These changes are being considered by the current SISO C4I — Simulation TRM Study 
Group, and are expected to become part of the formal C4I — Simulation TRM (C4I/Sim TRM). Section 2 
of this paper provides an overview of the proposed C4I/Sim TRM, with additional detail in the source 
paper [2] and study group sourcebook [6]. 


The remainder of this paper is organized as follows: Section 2-4 provide an overview of the C4ISR/Sim 
TRM, Section 5 provides an introduction to various analysis sections which follow (Sections 6-9), Section 
10 summarizes the result, with specific recommendations to the NATO Modelling and Simulation Group 
(NMSG). 


2.0 C4I—-M&S INTEROPERABILITY TRM OVERVIEW. 


The C4I/Sim TRM is intended to be a generalized model of the components and interactions that are 
considered significant to efforts to establish interoperability between C3I and_ simulation 
systems/components, regardless of application for the interface effort. It is NOT intended to represent any 
specific simulation system, or current/future interface. Any level of detail within the C3I system has been 
intentionally omitted, as these systems are generously described in other documentation, such as the US 
DOD TRM [10,11] or NATO TRM[16 - 20]. The detail within the simulation system is kept at a high 
level of components that might be candidates for distribution in an architectural design. Another purpose 
for the high level Sim components is to suggest those that might be interchanged with C3I components as 
found in the NATO Common Operating Environment (COE) “basket of products”. Finally, the level can 
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be used to suggest possible candidates for component level integration, both using simulation components 
on board the C3I system and also using C3I components to facilitate interoperability during interface 
efforts. The scope of the C4I/Sim TRM is intended to allow for the consideration of component level 
interoperability, as well as systems level interoperability between simulation(s) and C3I system(s). The 
C4I/Sim TRM is intended to be appropriate whether the application for the interface is training/computer 
aided exercises (CAX), C3I system evaluation/test, acquisition, or simulation based decision support tools 
residing on (or remote from) the C3I system. 


Changes in the way that C3I systems have been developed, in particular through the use of a Common 
Operating Environment (COE), have made them more modular or “component” based. Taking advantage 
of these changes, the interface community has more frequently re-used core components from C4I systems 
(e.g. message processors, database management systems, comms modules) in interfaces to reduce costs 
and improve interoperability. 


The goal of the TRM is to assist programs in achieving more effective levels of portability and 
interoperability in the following ways: 


By providing a consistent and common lexicon for description of interoperability requirements between 
diverse systems 


e By providing a means for consistent specification and comparison of system/service architecture 
e By providing support for commonality across systems 

e By promoting the consistent use of standards 

e By aiding in the comprehensive identification of information exchange and interface requirements 


Although the TRM is based on current and past project experiences, it is intended to be evolutionary and 
flexible enough to support future needs, regardless of range of requirements or architecture configuration. 
Users are encouraged to use the TRM for guidance, and extract only those elements that support their 
specific project needs. 


3.0 TRM INTERACTION CATEGORIES 


Connecting the separate systems (or components) are /nteractions, which are collected together into 4 
categories. These categories of information exchange include service-oriented groupings for each 
domain’s systems (C4I, Simulation) and the core data that would be of interest to both systems (Persistent 
and Non-Persistent data) during interface and/or integration activities. In two cases (Simulation Service 
and Non-Persistent Data) individual lines are detailed to represent individual classes, while in the others a 
single line reflects the entire class, with examples of information exchanges provided for consideration. 
The reason for the distinction between generalized categories and specific interactions is that in the 2 
detailed categories cases sufficient work has been done to identify the specific classes, and it is expected 
that these classes are complete. An additional reason for the distinction is that in the two well-defined 
categories, the information exchanged is generally referred to in a similar way within the M&S and (31 
communities. 


To contrast this against the remaining two general categories (Persistent Data, C4I System Service), the 
lists presented are considered representative, and subject to variability depending on the C3I system. 
Further, it is felt that to completely enumerate all possible classes of information within these categories 
for all possible C3I systems would be of little use. Instead, an examination of requirements for each C3I 
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system (or component) interface is needed, and consideration of the actual classes within each category (as 
well as its relevance to the interface design) is suggested. 


Finally, the use of bi-directional arrows suggests the possibility that information flows within each class 
may go from C3] to simulation, or reverse. Clearly the existence of a particular class as well as whether it 
flows in a single direction, or both directions, is up to the requirements and design of the interface. What 
follows is a general description of the 4 categories. Additional information on Categories and Interaction 
details can be found in the source paper [2] and C4ISR/Sim TRM study group sourcebook [6]. 


3.1 Simulation Service Interactions 


To facilitate the distribution of simulations, yet allow them to be accessible to C3I systems, interactions 
such as those defined within this category are necessary. These include not only information “about” the 
simulation (reflecting the potential that a variety of simulations are available), but also the ability to 
control or coordinate its execution with (31 resident activities, the transmission of possible visualization 
data (although not necessarily images), mechanisms for data collection from one to another, and the net 
results (or “simulation effects”) of a simulation execution. 


3.) Non-Persistent Data 


Non-Persistent Data identifies very frequent information exchange interactions (typically messages, 
reports, or data replication) that may occur between C3I and simulation systems (or components). It 
represents the major focal point for interfaces used for training and CAX. In these applications most effort 
for interfaces goes into generating products from simulated entities, or evaluating products from 
operational C3I systems. In considering the potential use of these interactions within a simulation 
enhanced (31 system, it is possible that data from operational sources may be duplicated in forms such as 
these. This would allow the use of up-to-date situation awareness data in Course of Action Analysis 
(COAA) or Mission Rehearsal while additional data is received by operational components. Subsequently, 
revised data might flow through these classes to provide last minute checks against plan for feasibility. 
During actual mission execution, these classes might provide valuable conduits through which data used 
for automated execution monitoring might occur. 


3.3 Persistent Data 


This category represents operational data stores native to the C3I system, and having the characteristic of 
infrequent changes through the course of a simulation execution. Its presence within an interface, 
however, is important. The ability to provide direct transfer of C3I data from suggested sources to 
simulation equivalents for scenario initialization purposes can provide substantial cost savings, set-up time 
reductions, and increased flexibility for simulation use. Significant results from this type of work are 
reported in papers such as Furness et al, “Realtime Initialization of Planning and Analysis Simulations 
Based on C4ISR System Data” [12]. 


3.4 C41 System Service Interactions 


These are interactions that may be mandated by use of particular C31 components, or merely by virtue of 
being connected to a C3I system. They may not contain “data” that is exchanged between the two 
domains, but may be required in order to connect to the C3I system, sustain the connection, or to use a 
particular C3I component. In the absence of these interactions, the C3I system may fail, the interface may 
not be recognized as a valid C3I system (versus a commercial hardware/software platform), or be unable 
to communicate with a particular component. These types of interactions tend to be very C3lI 
system/component specific, based on particular component selections, hardware/software architecture 
implementation, or C3I system version. Therefore, no attempt is made to enumerate them exhaustively. 
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Rather, two general types are identified for illustrative purposes. 


4.0 Simulation System Components 


The concept behind simulation component modules is that they should represent the smallest reasonable 
piece that might be a candidate for distribution in an architectural design. In fact, they could potentially 
represent individual “services” distributed and tied together with the Run Time Framework. Further, they 
need not be a single instance, but could be multiplied across an implementation network. This would be 
true if used to design client/server configurations. This serves to recognize the simulation community’s 
work on developing “federations” of simulations. In addition, it also extends the possibility to consider 
that such “federations” may be available to C3I systems, which might control selection of federates used 
to produce simulated results via guidance provided through Simulation Metadata interactions. 


The simulation system components represented in Figure 1 are generalizations that would be considered 
most useful for, or relevant to C3I to simulation interfaces, or potentially useful for integration between 
systems. It is not intended that the components identified here represents a complete set required for any 
simulation system. Further refinement of the C4ISR/Sim TRM may expand this area, or ultimately there 
may be an effort to define and establish a reference model for simulations or synthetic natural 
environments. To date, beyond the work done on the C4ISR/Sim TRM described as part of this (and 
earlier) paper and the SISO study group, there has been no effort to put forth an M&S reference model, 
although the author believes there may be some value in doing so. There has also been little effort to 
establish a common M&S implementation (e.g. M&S COE). It may be possible that such efforts will be 
undertaken in the future, and as a result (as described in [8]) interoperability and reuse of simulation 
components will be improved. 


In the absence of an accepted M&S Technical Reference Model, components are included in the 
C4ISR/Sim TRM for the purposes of architectural design consideration. Further efforts for C4ISR/Sim 
TRM refinements in the simulation system components area include an examination of its completeness 
against the work of the European Co-operation for the Long-term In Defence (EUCLID) project [21]. A 
comparison against the EUCLID synthetic environment architecture, as well as components contained 
within the EUCLID repository may confirm the accuracy of this area of the TRM, or provide clues how it 
could be appropriately refined. As an alternative, additional abstractions for the simulation components 
may come from examination of the component architectures of such systems as OneSAF [13]. 


5.0 NATO MODELS & STANDARDS RELEVANCE INTRODUCTION 


Part of the work of the first SIW TRM Study Group [3] was to identify 5 guiding principles for the 
development of a C4ISR/Sim TRM. This work concluded that the C4ISR/Sim TRM must be: 
Comprehensive, Traceable, Easy to Interpret, Usable, and Independent. It also presented a cursory look at 
several M&S and other reference models, although it did not establish or reflect the relationship 
(traceability) between the C4ISR/Sim TRM and these other reference models. This paper seeks to 
establish the relevance of the C4ISR/Sim TRM to the international NATO community by examining 
several NATO reference models and standards, and illustrating their relationship to the C4ISR/Sim TRM 
in greater detail. 


The Software Engineering Institute (SEI), in their Software Technology Review [9] states: “Much 
confusion exists regarding the definition, applicability, and scope of the terms reference model, 
architecture, and implementation.” They go on to provide definitions for these terms (Table 1) and 
illustrative examples of the relationship between these concepts. In keeping with the SEI definition for 
reference model, the C4ISR/Sim TRM is intended to be a description of all possible software components 
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or component services and the relationships between 
them. 


Although repeatedly considered, no effort has been 
made to identify specific (or abstract) components 
for the C3I system portion of the diagram. The 
rationale for this is that C3I systems are subject to 
their own reference models (e.g. DoD TRM, NATO 
TRM), architectures (e.g. JTA, NATO C3 Technical 
Architecture), and implementations (e.g. DoD COE, 
NATO COE). Underlying each of these are 
sustainment efforts to continually evaluate and 


ORGANIZATION 


Reference Model: A reference model is a 
description of all of the possible software 
components or component services (functions), 
and the relationships between them (how these 
components are put together and how they will 
interact). 


Architecture: An architecture is a description of 
a subset of the reference model’s component 
services that have been selected to meet a 
specific system’s requirements. In other words, 
not all of the reference model’s component 


maintain reference and usage documentation. With 
all of these instances, the goal (among others) is to 
establish, guide, measure, or improve 
interoperability between systems or components. As 
with these efforts from the C3I domain, that is a 
primary goal of the C4ISR/Sim TRM. 


services need to be included in a specific 
architecture. There can be many architectures 
derived from the same reference model. The 
associated standards and guidelines for each 
service included in the architecture form the 
open systems architecture and become the 


: . . . ; criteria for implementing the system. 
In the following analysis sections the discussion P " 


starts with showing the traceability from the 
C4ISR/Sim TRM to the NATO TRM (NTRM). 


The 


Implementation: 
product that results from selecting, reusing, 
building, and integrating software components 
and component services according to the 
specified architecture. The selected, reused, 


implementation is a 


As an architecture is considered a subset description 
of a reference model for a particular domain, the 
NATO C3 Technical Architecture (NC3TA) is 
considered to be relevant in the domain of NATO 
C3I systems. The NC3TA provides the principal 
source of procedures, architectural concepts, data 
(standards and products), and their relationships, 
from which the Technical View of C3I systems or 
“system of systems” can be developed. From such a 
defined architecture individual C3I systems are 
composed. 


and/or built components and component 
services must comply 100% with the associated 
standards and guidelines for the implementation 
to be considered compliant. 


Table 1 - SEI Definitions 


This paper seeks to argue the relevance and validity of the C4ISR/Sim TRM to the NATO community, 
and its potential relationship to the NC3TA. To do so, an examination of the traceability of the C4ISR/Sim 
TRM to various portions of the NC3TA is considered. In particular, Section 7 looks at the NATO COE 
(NCOE) and NCOE Component Model (NCM). Section 8 proposes a simulation server functional 
configuration, and Section 9 relates the C4ISR/Sim TRM to the NC3TA Interoperability Model. 


6.0 NATO TECHNICAL REFERENCE MODEL (NTRM) 


The NTRM [17] provides guidance to NATO developers, system architects, and individuals in using and 
developing systems and technical architectures. The model promotes open system design, as well as the 
decoupling of application and external environment from the operating platform. It is based on national 
defense (US DoD TRM), aerospace (NASA Space Generic Open Avionics Architecture Model), and 
automotive (SAE GOA model) industry efforts. The NTRM contains basic elements of the POSIX OSE 
Reference model, which includes three classes of entities (Application Software, Application Platform, 
External Environment) and two types of interfaces (Application Program, External Environment). The 
main purpose of the NATO TRM (NTRM) is to structure the standards listed in the NATO Common 
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Standards Profile (NCSP) [19]. C4ISR/IM&S TRM NATO TRM relevant Application and 
Module System Service Areas 


Within the NTRM, there are 12 
service areas defined, which are 
later used organize standards within System Management Services 
the NCSP. In addition, there are 7 
application types (Mission Area 
Applications and 6 Support types). 
In order to assess the relationship Simulation & Models Mission Area Application 
between the NTRM and C4ISR/Sim | Module Engineering Support Applications 
TRM, an attempt was made to map Common C2 Applications Services 
the simulation modules into the 
various services and applications 
described in the DoD TRM. The 
results are presented in Figure 2 and 


Simulation Control User Interface Services 


Visualization User Interface Services 
Graphics Services 


Simulation Engine Mission Area Application 
Engineering Support Applications 
Common C2 Applications Services 


discussion of the results follows. Models Mission Area Application 
Engineering Support Applications 
In general, each module was able to Common C2 Applications Services 


map to several NTRM services 
and/or applications. This reflects the 
fact that as a reference model, it 


Run-Time Framework Distributed Computing Services 
Data Interchange Services 


represents a potentially unlimited | Databases Database Utilities Applications 
number of architectural definitions Data Management Services 
and/or implementations. In several 


cases, the modules were 
successfully mapped to items in both 
the service and application 
categories. This would credit the fact that simulations, due to their power and flexibility, can be seen to 
provide both application capabilities to the end-user, as well as perform service level functions to the 
system and/or other applications. 


Figure 2 - C4ISR/Sim Mapping to NTRM 


For the C4ISR/Sim TRM Simulation Control module, the limited descriptions provided for NTRM service 
areas suggest that a relationship would exist between Simulation Control module and NTRM User 
Interface Services, or NTRM System Management Services, or both. Clearly, the simulation control 
module might represent the user interface to the simulation “service” and provide management capabilities 
for it. But depending upon the specific architecture, it may (or may not) provide a user interface, style 
sheets, direct access to simulation capabilities, etc. If the user interface services class was intended to 
represent only those on-board capabilities to construct and control user interfaces (e.g. browser, 
Xwindows) then the simulation control module would be squarely within the system management services 
area. 


Similarly, the Visualization module could map to one of two different NTRM service areas, either User 
Interface services or Graphics services. In this case, the visualization may represent intermediate results of 
simulation activities. Often this would be displayed on some form of two dimensional planned view 
display (PVD) or possibly overlaid onto a map. The potential mapping to User Interface Services might 
assume the development and acceptance of a simulation domain standard PVD or Graphic Information 
System (GIS) as a User Interface Service. In contrast to a similar evaluation of the C4ISR/Sim TRM 
against the US DoD TRM [15], the Visualization module was mapped easily to the Multimedia Services 
category not present in the NTRM. In the US DoD TRM, the Multimedia Services category contains a 
descriptive reference to GIS services, while the Graphics Services (within NTRM) simply refers to 
“functions required for creating and manipulating pictures.” 
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The simulation and models aggregate component might be instantiated as a Common C2 Application, or ἃ 
stand-alone Mission Area Application. Further, it is also identified as a potential Engineering Support 
application. Unfortunately, there is an absence of descriptions for applications (including Engineering 
Support) within NTRM documents available, however the US DoD TRM Engineering support description 


refers to “decision support services”, “modeling and simulation services”, and “expert system services”, 
all of which are potential applications for modeling and simulation interfaces or integration. 


Although simulation engine(s) or model(s) are highly unlikely to be embedded (or interfaced to) by 
themselves, the possibility exists. As an example, it might be desirable to embed a simulation engine, 
which dynamically loads models (as data parameters, executable components, etc) from some central 
repository. Therefore, these would have the same potential mapping as the simulation and models 
aggregate component. Other then this possibility, more obscure mappings could be made (e.g. Simulation 
Engine — Mission Area Application / Models — Data Management Services). 


Finally, both Run-Time Framework and Databases could map into two categories, depending principally 
on the intended implementation architecture. In the case of the Run-Time Framework, perhaps the more 
acceptable mapping would be into Distributed Computing Services. This is due to the fact that the 
Distributed Interactive Simulation (DIS) protocol is already an accepted standard within the NCSP for 
simulation use. 


It was consideration of the module mappings that reinforced that the NTRM is a very generalized model 
and as such cannot (or has not yet) identified all possible domain services that could be provided. Also, 
there is presently limited documentation to describe various entities, applications, and service areas, which 
makes a specific direct mapping difficult. However, in several cases (specifically Run-Time Framework 
and Databases) descriptions provided within NTRM documents provides a somewhat clearer definition as 
to the potential implementation method or purpose for the modules. Therefore, although there is value in 
considering a mapping to NTRM areas for the purposes of communication with systems designed and 
built using this model, there is still relevance to a domain specific model such as the C4I/Sim TRM, which 
contains descriptions that should be more clear to simulation domain practitioners. However, the most 
ideal solution might be the use of both reference models for a more complete description of architectural 
components, modules, and implementation possibilities. 


7.0 NATO COMMON OPERATING ENVIRONMENT (NCOE) 


The goal of the NCOE is to support the development of a distributed information system infrastructure, 
which promotes interoperability. The NCOE provides the minimum set of services, common standards 
profiles, management procedures, implementation rules, interfaces, and guidelines for product selection, 
as well as products to implement NATO Information Systems (NIS). The objective is to ensure their 
interoperability within NATO and with national systems. 


The NCOE Component Model (NCM) [20] capitalizes on the NATO Technical Reference Model 
(NTRM), utilizing its top-down layered architecture. Individual components can be described as the 
individual capabilities that are transparent to the end-user. Components are in essence the distributed 
computing capabilities, data interchange services, management services, communications services, data 
management services, presentation services, security services, etc. that are inherent to the NCOE as 
depicted in the NCM in accordance with the NTRM. The NCM depicts the high-level functional 
taxonomy and overall composition of the NCOE. Within the NCM, each individual component is 
categorized according to the type of service provided. However, the NCM only provides a view of 
individual component relationships by service area only. The actual products necessary to populate each 
service area are selected from the NCOE ‘basket of products’. 
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C4ISR/M&S TRM NCM Service Areas NCM Service Sub-Categories 
Module 
Simulation Control Infrastructure Services Management Services 


ΠΗ Common Support Services Enterprise Management Services 
Visualization Common Support Services Graphical Services (or) 
Undefined 


Simulation & Models Common Support Services Common C2 Application (or) 
Module Undefined 


Simulation Engine Common Support Services Common C2 Applications (or) 


Undefined 


Data / Objects (or) 
Undefined 
Run-Time Framework Infrastructure Service Communications Services 
Distributed Object Services 
Infrastructure Service Data Management Services 


Figure 3 - C4ISR/Sim TRM to NCM Mapping 


An analysis was done to reflect the mapping between the C4ISR/Sim TRM and the NCM. The results are 
provided in Figure 3. However, as described in the details below, a number of simulation specific services 
(or components within the C4ISR/Sim TRM) remain difficult to classify. 


Visualization would seem to be implementation dependent, but could be subject to some confusion based 
on the underlying technology chosen for implementation. For example, simulation displays that were 
based on GIS packages would clearly be able to fit within the Geospatial Services category. However this 
category seems to be identifying those components that are end point GIS systems, rather then simulation 
adaptation of these products that provide “added value” (e.g. displaying simulation progress on map 
products). Further, several existing simulations considered during the development of the C4ISR/Sim 
TRM utilize “home grown” PVDs, based on X Window, OpenGL, or VRML technologies (for example). 
These technologies/components are suggested within the presentation/multimedia services area, and 
therefore it may be appropriate for these Visualization components to reside there. Yet instances exist 
where simulation visualization tools may be distributed independent of the simulation portion itself, so 
correct placement within the NCOE may be important. 


Similarly, Models do not easily fit into a single component category, because of the “value added” that 
they provide. Potentially instantiated as a model repository, they may consist of data files or objects, with 
their own repository infrastructure. However, this does not necessarily qualify them for data management, 
or distributed object services if these categories refer to domain independent tools. Clearly at some level 
they represent “data” or “objects”, but specific to the M&S domain and in conjunction with (or without) 
the Simulation Engine they represent a potentially powerful “service” that can be invoked by other 
applications, or as mission applications themselves. 


The Simulation & Models module and Simulation Engine component doesn’t fit easily within Common 


Support Services or Infrastructure Services Categories. As a default, they were associated with the 
Common C2 Application service, although they did not seem to be consistent with the service description 
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Figure 4 - Proposed Functional Components for Simulation Server 


provided. Simulations, models, and simulation engine products exist in a variety of forms, not only from 
commercial vendors but also as by-products of nationally sponsored simulation efforts. As stated in [20] 
“The primary intent of the Common Support Applications is to provide the architectural framework 
necessary for the management, distribution and sharing of information among applications throughout a 
system.” Further, “Infrastructure services provide a set of integrated capabilities that the applications will 
access to evoke NCOE services, and are necessary to move data through the network.” Based on the 
examination of these definitions and other documentation of existing services categories, it was considered 
that a clear direct mapping of these simulation components was difficult. 


As a result, it may be of value for the NMSG to consider development and proposal of an additional 
Common Support Service category. This category might be specifically oriented toward simulation-based 
applications or more generalized decision support services. These might not be mission applications 
themselves, but could provide powerful simulation based information processing or analysis capabilities to 
a wide audience of Mission Application developers. They could also represent the domain specific 
versions of various other services/applications (e.g. visualization, model repositories) that could be shared 
among simulation developers, or instantiated onto C3I systems. 


As an example category, “Decision Support Services” might apply to a category of service level 
applications that provide intermediate processing of data/information from lower level (Infrastructure 
Service) components or data sources. Yet these “Decision Support Service” components may be general 
enough that they can be reused based on a common input format/standard and appropriate APIs. To extend 
the recommendation, it could be considered a “base” component, similar to “Document Management”, 
“Message Handling”, “Office Automation’, or “Geospatial Services”. 


8.0 REFERENCE MODELS FOR FUNCTIONAL CONFIGURATIONS 


Volume 2 of the NC3TA [17] introduces Functional Configurations (FC), which are composed of 
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application and foundation services and interface functionally with one another. A full overview of FCs is 
provided in Annex B, and shows 9 FC examples that constitute an initial, although not all-inclusive list of 
FCs that will be validated and/or updated in future versions of the NC3TA. An examination of the existing 
FCs resulted in none that appeared fully appropriate for a simulation server configuration. As a further 
evaluation of the utility of the C4ISR/Sim TRM, a proposed FC configuration was developed and appears 
as Figure 4. 


The motivation of a simulation server FC is the same as other FCs. It can be used to reduce architectural 
complexity, promote and encourage the judicious use of NCOE components, and improve interoperability. 
These and other reasons are consistent with recommendations made to SISO for the establishment of an 
M&S COE in a recent paper entitled: “Interoperability and Reuse through a Modeling and Simulation 
Common Operating Environment” [14]. Further motivation can be seen through the existence of other 
“server system” FCs, including Database Server, Web Portal/Application Server, Documentation 
Management Server, Messaging and Communications Server. 


9.0 NC3TA INTEROPERABILITY MODELS 


In order to classify NC3I Interoperability, the ISC has included in their NATO Policy for C3 
Interoperability (PO(2000)39), 4 degrees of interoperability. These degrees are broken down into sub- 
degrees and are intended to classify how structuring and interpretation of data can enhance operational 
effectiveness. The sub-degrees are then be mapped to groups of standards to be referred to during the 
selection process. 


To show the relationship between the C4ISR/Sim TRM and the applicable standards within the NC3TA, a 
mapping was done from the various interaction classes within the model to the interoperability sub- 
degrees within the NC3TA. This mapping is represented below, with specific point discussions to follow. 
The utility of such a mapping is that it provides a guide to interface efforts as to which categories of 
standards need to be considered during their efforts. It can also serve as a roadmap for NMSG standards 
consideration/development effort to focus on those categories where relevant standards are missing. 
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TRM Major Interaction NATO | Sub-Degree Name Notes: 
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Soanen Simulation Enhanced Document 
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Execution Basic Informal 
Control Me Message Exchange Dina eren 
Vigualeaton 2B Enhanced Document | Moving Image/Graphical 
Exchange Image 
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2.D : overlays, military 
Graphics Exchange 
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Simulation Various forms: hypertext, 
Effects graphical, data file 
Non-Persistent Onde 3A Formal Message 
Data Exchange 
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TRM Major Interaction NATO | Sub-Degree Name Notes: 
Category Class ID 
Formal Message 
Reports 3.A Exchange 
Graphical/still image 
aes 2B Enhanced Document | data, moving image, 
ory : Exchange audio/visual data 
exchange 
Tracks 3.B Common Dara Services for DBMS 
Exchange 
3.F Bee Pune Dats Tactical data links 
Exchange 
: Common Data ee 
Unit Data 3.B Database Replication 
Exchange 
: Enhanced Informal 
Persistent Data 2.A Message Exchange Message Logs 
Map/Overlay : : : 
2.D Graphics Exchange Terrain Specification 
Data Object 
2.H Exchange Message Logs 
3.B Comtnn Pale Database 
Exchange 
C4ISR Service Network 
: 2.0 
Interactions Management 
3.C System Management 
3D Secure System 
; Management 
Security 
aE Management 


Figure 5 - C4ISR/Sim TRM Mapping to NATO Interoperability Degrees 


The Non-Persistent data interactions mapped easily to the categories that would be expected for 
components and/or interactions among C3I systems. In cases where mappings indicated above were 
incorrect, users of the C4ISR/Sim TRM would be expected to utilize the interoperability profile for the 
specific machine (or type of machine) that was subject to interface or integration. 


As indicated in the C4ISR/Sim TRM source paper [2], the items within the Persistent Data and C4ISR 
System Service categories are considered representative and subject to variability depending on the (41 
system or proponent service. Therefore, the mappings in these two categories are also generally suggestive 
rather then attempting to make a single correspondence. In these two cases, no specific details for 
interactions are made, but general selections for sub-degrees represent common categories for items 
contained within the Notes column. 


Identifying and categorizing the various simulation service interactions into sub-degrees was somewhat 
easier, yet subject to the same level of variability. The most likely form for simulation meta-data would 
seem to hypertext or XML formatted messages. For the purposes of simulation execution control, the 
example of legacy system usage of specific protocols, such as Distributed Interactive Protocol (DIS), 
Aggregate Level Simulation Protocol (ALSP), as well as current use of the High Level Architecture 
(HLA) Run Time Infrastructure (RTI) were considered. Of these, only DIS is referred to in the NC3TA 
standards document [18], although NATO acceptance of the HLA has occurred. 
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Data collection can take the form of discovery (and transfer) of numerous items from the C4ISR system, 
and potentially from the simulation. As a result, the sub-degrees that would be applicable would be as 
wide as the set of items for each system individually. Research in the area of simulation effects is still 
relatively new, and therefore difficult to classify the form that it might take. It could be a representation of 
a hypertext document (2.B), or perhaps a rendering on a Graphical/GIS image (2.D). Ultimately it may 
represent the influence of a particular datafile or operational database that is returned to the C3I system. 


10.0 SUMMARY 


This paper has provided an overview of the evolving C4ISR/Sim TRM, and examined the traceability of it 
to the various component reference models and standards of the NC3TA. The importance of the 
traceability to aid on-going efforts to establish C3I to simulation interfaces, the use of COE components 
within those interfaces, and the desire to migrate simulation based components and applications onto C31 
systems. In the absence of an accepted (or mandated) simulation TRM, the simulation community has 
been free to model, architect, and implement what they choose. However, if those components are placed 
directly onto a C3I system, they would be subject to the models, architecture, COE, and standards as 
defined within the NC3TA. 


As the analysis has shown in many cases, obvious relationships exist between components (and 
interactions) of the C4ISR/Sim TRM (and by extension the simulation domain) and the NC3TA. In other 
cases, the relationship is more obscure, principally due to the “generic” nature of the NC3TA. However, it 
has been pointed out where simulation domain specific contributions can be made within the framework of 
the NC3TA, that would help to make it more relevant to the simulation community. Through efforts such 
as this, it is suggested that the task to establish interfaces, and integrate components would be made easier, 
and the results more interoperable. 


The following are the summary of the specific recommendations to the NMSG for this effort: 


e Development and recommendation of simulation based Common Support Service category, for 
inclusion within the NCM. 


e Development and formalization of Simulation based Functional Configurations, Technical 
Configurations, and Internal Interoperability Profiles. 


e Identification of additional simulation based standards (e.g. HLA, SEDRIS) for inclusion in 
NCSP. 


e Examination of C4ISR/Sim TRM to ensure that lexicon and representations are sufficiently 
generalized and consistent with NATO standards. 


e Further examination of validity of C4ISR/Sim TRM, and consideration of Annexed inclusion 
within the NC3TA. 
11.0 ACKNOWLEDGEMENTS 
I would like to express my extreme appreciation to those reviewers who donated their valuable time to 
examine preliminary work, read this paper, thoughtfully consider the ideas, and provide their insightful 
feedback. Their contributions helped clarify, refine, and shape the contents. 
My affiliation with The MITRE Corporation is provided for identification purposes only, and is not 


intended to convey or imply MITRE's concurrence with, or support for, the positions, opinions or 


RTO-MP-MSG-022 18 - 13 


C4ISR/Sim TRM Applicability to NATO Interoperability ΘΒΘΑΝΧΖΑΤΥΡΟΝ 


viewpoints expressed in the paper. 


12.0 REFERENCES 


[1] 


[2] 


[3] 


[4] 


[5] 


[6] 


[7] 


[8] 


[9] 


[10] 


[11] 


[12] 


[13] 


[14] 


[15] 


[16] 


Carr F, Hieb M R, “Issues and Requirements for Future C4ISR and CGF Interoperability”, 
07CGF052, 1998 Computer Generated Forces Conference, Orlando, Florida, Sept 1998. 


Carr F, “Examining the C4I - M&S Technical Reference Model”, 03S-SIW-014, 2003 Spring SISO 
Simulation Interoperability Workshop, Orlando, Florida, Apr, 2003 


Timian, D.H., Hieb, M.R., Lacetera, J., Tolk, A., Wertman, C., and Brandt, K.: “Report Out of the 
ΟΖ] Study Group”, Paper 0O0F-SIW-005, 2000 Spring Simulation Interoperability Workshop, 2000. 


Myers, et al, “Interim Report of the C4ISR/Sim Technical Reference Model Study Group, Paper 
01F-SIW-094, 2001 Fall Simulation Interoperability Workshop, Orlando, FL, September 2001. 


Griffin A, Lacetera J, Tolk A; Editors, “C4ISR/Sim Technical Reference Model Study Group Final 
Report”, Paper 02F-SIW-022, 2002 Fall Simulation Interoperability Workshop, Orlando, FL, Sept 
2002. 


Carr F, Caylor J, Lacetera J, Tolk A, “C4ISR/Sim TRM Sourcebook”, 03F-SIW-124, 2003 Fall 
SISO Simulation Interoperability Workshop, Orlando, Florida, Sept, 2003 


Caylor J, Lacetera J, “A User Guide to the SISO C4ISR/SIM Technical Reference Model”, 03F- 
SIW-125, 2003 Fall SISO Simulation Interoperability Workshop, Orlando, Florida, Sept, 2003 


Carr F, Myers L, “Interoperability and Reuse through a Modeling and Simulation Common 
Operating Environment”, Paper 02S-SIW-016, 2003 Spring Simulation Interoperability Workshop, 
Orlando, ΕἸ, Mar 2003 


Software Engineering Institute, “C4 Software Technology Reference Guide”, 
http://www.sei.cmu.edu/technology/str/ 


US Department of Defense, “DoD Technical Reference Model”, Ver 2.0, 09 Apr 2001 

US Department of Defense, “DoD Technical Reference Model User Guide”, Ver 1.0, 10 Apr 2000 
Fumess, Z., Isensee. E., Fitzpatrick, M.: “Realtime Initialization of Planning and Analysis 
Simulations Based on C4ISR System Data” Command and Control Research and Technology 
Symposium (CCRTS), June 11-13, 2002; Naval Post Graduate School, Monterey, California. 


Wittman, Harrison, Williams, “The OneSAF Objective System: Block A Development”, 2002 
European SIW, 02E-SIW-033, June 2002 


Carr F, Myers L, “Interoperability and Reuse through a Modeling and Simulation Common 
Operating Environment”, 03S-SIW-016, 2003 Spring SIW Conference, Orlando, FL, Mar 2003 


Carr F, “Understanding the C4I - M&S Technical Reference Model, other Models, and Standards”, 
03F-SIW-070, 2003 Fall SIW Conference, Orlando, FL, Sept 2003 


ISSC NATO Open Systems Working Group, “NATO C3 Technical Architecture Volume I - 


18 - 14 RTO-MP-MSG-022 


C4ISR/Sim TRM Applicability to NATO Interoperability 


Management”, http://194.7.79.15/volumel/index.html , Version 4.0, 7 March 2000 


[17] ISSC NATO Open Systems Working Group, “NATO C3 Technical Architecture Volume II - 
Architectural Descriptions And Models”, http://194.7.79.15/volume2/index.html , Version 4.0, 7 
March 2003 


[18] ISSC NATO Open Systems Working Group, “NATO C3 Technical Architecture Volume III - Base 
Standards And Profiles”, http://194.7.79.15/volume3/index.html , Version 4.0, 7 March 2003 


[19] ISSC NATO Open Systems Working Group, “NATO C3 Technical Architecture Volume IV - NC3 
Common Standards Profile (NCSP)”, http://194.7.79.15/volume4/index.html , Version 4.0, 7 March 
2003 


[20] ISSC NATO Open Systems Working Group, “NATO C3 Technical Architecture Volume V - NC3 
Common Operating Environment (NCOE)”, http://194.7.79.15/volumeS/index.html , Version 4.0, 7 
March 2003 


[21] Ford K, “Euclid RTP11.13 “Realising the Potential of Networked Simulation in Europe”, 01E-SIW- 
011, 2001 European SIW Conference, London, UK, June 2001 


13.0 AUTHOR BIOGRAPHY 


Francis H. Carr is a Lead Simulation Software Engineer with the MITRE Corporation. A Boston 
University graduate, he earned his MS degree from George Mason University in software engineering. 
Since 1975, he has been involved with the development of a range of applications including artificial 
intelligence, reliability engineering, mathematical systems modeling, and business systems. Since joining 
MITRE in 1996, he has worked with both civilian (FAA) and military simulations and has developed and 
consulted on a number of simulation-C4I interfaces. He has served as an Architect with the Army 
Simulation to C4ISR Interface Overarching IPT (SIMCI OIPT), and for DMSO as the chairman of the 
COE M&S TWG. He has written over 12 papers on simulation, C4ISR, interface research, and 
interoperability topics. He has also been a repeated presenter of tutorials on C4ISR systems, Simulations, 
and Interface issues. 


RTO-MP-MSG-022 18-15 


ORGANIZATION 


C4ISR/Sim TRM Applicability to NATO Interoperability 


| 
ΒΡ ἈΝΕ 
YW 
| 


18 - 16 RTO-MP-MSG-022 


Paper presented at the MSG-022/SY-003 Conference on “C3I and M&S Interoperability”, 
held in Antalya, Turkey, 9-10 October 2003, and published in RTO-MP-MSG-022. 


ALLIED COMMAND TRANSFORMATION ROLE IN 
MODELLING AND SIMULATION 


Commodore Jon WELCH 
UKN DACOS FC&RT HQ SACT 
7857 Blandy Road 
Norfolk, VA 23551 
USA 


1. The purpose of this presentation is to give you an update on the Transformation process 
that has taken place within NATO and in particular, the Supreme Allied Commander 
Transformation (SACT) HQ. How we at SACT see ourselves interfacing with R&T organizations 
and agencies and more specifically, how modeling and simulation will play an important role in 
this process. 


2. To effect a cohesive, collaborative and focused transformation, our leaders decided at the 
Prague Summit in November 2002 designated a command to be the driver for change within 
NATO. To function as the focal point for managing the range of issues affected by 
transformation: interoperability, jointness, experimentation, education, and conceptual and 
doctrinal development. In order to ensure that we find new ways to sustain and improve our 
ability to fight as an interoperable allied team, Allied Command Transformation was established 
with responsibility for managing differences in capabilities as our militaries innovate and 
technology provides them new tools. 


3. Allied Command Transformation has been assigned the mission of leading the 
transformation of NATO forces. It will be accountable for producing forces that bridge the 
difference in alliance capabilities and capitalize on the competitive advantages of national 
contributions. Supreme Allied Commander Atlantic transitioned to become the Transformation 
Strategic Commander for NATO on June 19 2003. SACEUR became the sole Operational 
Strategic Command through a realignment of functions/ tasks along an operational/functional 
line. The NATO Transformation process is now established allowing one command to be the 
driver for change, to provide the focused effort necessary to advance new technology, policy and 
doctrine within the Alliance. This one command will have the ability to concentrate on 
Transformation with the other strategic commander focusing on operations. Allied Command 
Transformation will be the advocate for new doctrine, concepts, and innovations within the 
Alliance. 


4. To bring about the Realignment of the two strategic commanders to realize on 
operational and one transformational command, the staffs of the two strategic command 
headquarters sat down to assess the tasks assigned to each. The staffs identified operational tasks 
to be transferred to SACEUR as the operational commander and tasks to be transferred to 
SACLANT in order to identify all tasks and insure there would be no decrease in the output of the 
two strategic commands as they transitioned to their new missions. 

It is with this realignment of tasks and we realize the mission and structure of the two new 
strategic commands. Here at HQ SACT we commenced operating as the transformational 
command on 19 June 2003 with the transfer of command authority of all operational assets to 
SACEUR, the deactivation of SACLANT and the activation of the Supreme Allied Commander 
Transformation. Over the course of the next several months the staffs will commence transfer of 
tasks, pending placement of budget and manpower at the applicable strategic command. 
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5. On 19 June 2003 with the activation of the Supreme Allied Commander Transformation, 
we were once again linked the US Joint Forces Command when their commander was once again 
dual hatted as the Strategic Commander for NATO here in Norfolk. The post for our commander 
is no longer gapped or filled in an interim capacity by the Deputy, but reflects the dual hatting 
with US Joint Forces Command. Our previous area of responsibility was the North Atlantic and 
we specialized in Maritime issues. As a result we have been manned by Navy Flag Officers. In 
an effort to become the Transformation command for NATO we are working with nations to fill 
posts with officers of other services. As you can see here we are making great strides. Our Joint 
Education and Training and C41 sub-divisions are being headed by Air Force General Officers, 
and we have Army General officers holding the positions at the Joint Warfare Center / Strategic, 
Concepts, Policy and Integration / and Defense Planning. 


6. We have organized ourselves into two major departments — Transformation and 
Transformation Support under which our divisions and sub-divisions are aligned. We area 
totally new command — in mission and in structure and there is no basis under which the two can 
be compared. When our Outline Peacetime Establishment for the headquarters is agreed by 
nations we will have approx 550 personnel here on staff at the Headquarters. Given the physical 
distance between HQ SACT and NATO HQ in Brussels, the position of the SACT Representative 
in Europe, or SACTREPEUR, cannot be understated. He and his staff are physically located at 
NATO Headquarters and are a vital link in providing SACT’s advice and perspectives to the 
political and military leadership of the Alliance on a daily basis. 


Ts The Sub-divisions are Implementation and Capabilities. We’ll first look at the 
Capabilities functions to give you a better understanding exactly what the term capabilities means 
and what some of our outputs will be. Liaison will be established with the US Joint Forces 
Command in Norfolk, Virginia for transformational efforts and strong ties will be established 
with the staff at the Allied Command Operations. To fully execute our tasks of providing 
education and training for allied personnel we will establish close working ties with established 
NATO schools and for experimentation purposes we will work closely with NC3A, NURC, the 
RTO, and national Centres of Excellence. 


8. We have made a lot of progress in a very short space of time, but there is a lot more to do 
yet before we consider ourselves fully transformed. This Status/timeline - presented in the 
Implementation Directive provided by the International Military Staff - is ambitious we know, but 
it is the goal that we are working hard to achieve. 


9. We think we are still ahead of the work - but this represents a very significant amount of 
work still to be accomplished in the near future. 

Deliver the Bi-SC DIP 30 Sep 03 

Obtain MC agreement on Flags to Post 15 Mar 04 

Final PE - MC agreement 30 Sep 04 

Begin manning of new PE posts by Nations from 1 Nov 04 

Declare NCS IOC by 30 Jun 05 

Declare NCS FOC by 30 Jun 06 

10. Transformation in the context of the Alliance is defined as a continuous process of 


development and integration of innovative concepts, doctrine and equipment in order to improve 
the effectiveness and interoperability of war-fighting forces. During this process the use of 
modeling and simulation provides us the capability to build and test our vision, concepts, doctrine 
and equipment this way we can create an environment in which the Alliance is pro-active rather 
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than reactive, and where capability requirements are anticipated rather than developed following 
emergence of new security threats. This continuous process starts by identifying future 
requirements for NATO forces and comparing them with current force capabilities and near term 
improvements to establish the extent of any shortfalls. Potential solutions will be identified in the 
form of concepts that can be developed and experimented within a collaborative manner with 
Modelling and Simulation. This concept work could involve the development of prototype 
equipment, and/or doctrine, training, infrastructure improvement. To support this, Strategic level 
operational analyses will be conducted to identify the type and scale of capabilities and 
interoperability that the Alliance will require. In parallel, ACT will acquire an in depth 
knowledge of both the Alliance's current capabilities and intended improvements to national 
capabilities in order to clearly establish where the Alliance needs to concentrate its future efforts. 
These will inform the Defence Planning Process and will result in a Strategic Transformation 
Vision that clearly identifies and prioritizes the Long Term Capability Requirements of the 
Alliance. As you can see modelling and simulation will be used every step of the transformation 
process. 


11. The following activities of the transformation process should be supported with 
modelling and simulation tools: 


Analysis of Capability Requirements 
Concept Exploration and Development 
Concept Experimentation 

Operational Training and Exercises 


12. Starting first with the analysis that is conducted to identify NATO’s capability 
requirements. This work involves the assessment of NATO’s capabilities in representative 
scenarios such that gaps in this capability can be identified. To do this work we need models that 
address the new situations that could confront us and methods for comparing various response 
options that NATO might take. These situations involve traditional combat, but also peace 
keeping, information operations and the military contribution to managing the consequences of 
terrorist attacks. Models should reflect the fact that we are becoming more joint and interoperable 
with various military and civil bodies in various NATO and non-NATO nations. Having 
identified capability areas that require attention, we need to develop concepts that address these 
capability gaps. In this case, M&S support is needed to evaluate these concepts, including the 
ability to measure the impact of the emerging technologies. One area that is particularly 
important is the application of M&S tools for the analysis of decision-making processes in 
multinational joint operations. Finally, we are recognising that some parts of the military 
capability spectrum are harder to simulate than others. For example, we have extensive M&S 
capability in support of logistics concepts but very little when it comes to information operations. 
Modelling and simulation has also an important role in the experimentation process. The 
simulation models allow examination of the real-world concepts in a simulated environment. The 
live domain is a representation of military operations using live forces. The virtual domain is a 
replication of actual war fighting equipment, systems and includes computer-generated 
battlefields in simulators. The constructive domain includes simulations that represent actions of 
people and systems in the simulation. Experiments could benefit from one or combination of 
these M&S domains. It is clear that training and exercises will play a major role in future efforts 
to transform NATO capabilities. In this context, we need a complementary set of M&S tools. 
These tools should include an advanced distributed learning capability to train the augmentees 
before the exercise such that they are ready to assume their responsibilities effectively. We need 
to educate and train them anytime, anywhere as needed. The tools used to support training and 
exercise events should be reusable and interoperable to cut down on the modelling cost, as they 
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should be multi-resolution to optimize their use at different levels of operations. The real world 
operational CCIS systems should become the backbone of these simulations. Embedded decision 
making tools could make them valuable during real operations. 
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NATO Annual Modelling and Simulation Conference 
“C31 and Modelling and Simulation Interoperability” 


Closing Remarks 


Mr Graham G. BURROWS, Head, NUSCO 
Conference Committee Chairman 
RTA - BP 25 
92201 Neuilly sur Seine, France 


Mr Burrows provided the following closing remarks: 


Summary of initial Key Points emerging from Conference: 

- Modelling and Simulation has a pivotal role in every phase of the NATO Transformation 
Conference. 

- There are many promising approaches, but we do not yet have good interoperability between 
M&S and (91 systems. 

- Knowledge of C3I systems architectures and dat/object models should be mandatory. There is 
still much education to be done in C3] and M&S. 

- Commercially supported open standards are increasingly being used as add-ons to specific M&S 
standards, in particular web services and XML. But, to align these approaches, overarching methods are 
needed. 


He thanked: 
- The National Hosts (Turkey) for hosting the Conference and for providing excellent support and 
facilities. 


- The participants for attending, providing excellent Papers and positive, stimulating questions and 
comments. 


- The Interpreters — It had been a real challenge keeping up with the many different accents and speeds of 
delivery, but as usual they rose to the challenge. 


He announced: 
- The next NATO M&S Conference will be held in Germany, on 7 and 8 October 2004 with the Theme — 
M&S to Address NATO’s New and Existing Military Requirements. 


He finally wished participants a safe and enjoyable journey home. 
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